[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: empath
From:       Harri Porten <porten () tu-harburg ! de>
Date:       2000-01-05 13:25:10
[Download RAW message or body]

On Wed, 5 Jan 2000, Dirk A. Mueller wrote:

> On Mit, 05 Jan 2000, Waldo Bastian wrote:
> 
> > I guess that NOW would be a good moment to move empath from kdenonbeta 
> > to kdenetwork.
> 
> It should be moved to a separate module imho. our way of handling
> applications in CVS is a little bit ugly and it should be changed. 

[ It's already well known that feel the same so I'll shut up this time and 
just report what was talked about in Erlangen ]

> We had that discussion shortly before KDE-II, and we agreed on discussing
> this stuff at the meeting directly. Unfortunately I couldn't travel to the
> meeting, so I don't know if it has been discussed and if there is already an
> agreement on the topic. At least it was nowhere mentioned. 

There *was* some discussion about it. No agreement was reached on 
actually restructuring the CVS but a simple idea came up:

The CVS modules are the developer's view of our code. They should be easy 
to handle and administrate. Stephan may share more detailed thoughts 
about this with us. End users - on the other hand - may be more 
interested in obtaining code in smaller quantities. Singling out a tar 
package of an application from a big module is technically feasible. Taj 
already wrote his cvs2pack script quite some time ago. This could even be 
automated by monitoring version.h in a module's subdirs. If the script 
that is run each night encounters an increased version number it would 
create a tar.gz file, upload it on our kde server, freshmeat etc.
 
> well anyway, with coolo's sophisticated configure system (kde-common/admin)
> and with the help of CVSROOT/modules, if empath is a separate module it just
> can be mapped into every package you want to by changing a single module
> line.  

The seperation into distinct configure.in.in files was a first measure to 
have a better modularity. As soon as we have a major release followed by 
bugfixes I'll be motivated enough to tackle the version.h problem.

Harri.

[prev in list] [next in list] [prev in thread] [next in thread]