On Mit, 05 Jan 2000, Harri Porten wrote:

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

There's no need to restructure the whole CVS. Just don't make the same
mistake over and over. 

> The CVS modules are the developer's view of our code. They should be easy 
> to handle and administrate. 

Exactly that's why I've suggested a separate module. what could be easier
to handle? It's easy to take out an application from the compilation process
of a kde* module (just remove the subdirectory in you local copy), it's easy
to take out in case it is outdated or if it should be replaced by something
better for a release (just a one-liner commit)

It doesn't make sense to bundle several apps into one module that just have
no inter-application-dependencies. A good example is kdeutils. You can
compile every application of that module separate. so there is no need to
bundle them together, _although_ they still can be released together (there
just needs to be an alias in CVSROOT/modules that defines what apps should
go to the kdeutils package this time). 

and it can be "mapped" into kdenetwork or kdepim with just _one_ _line_ of
source change. what else can be easier?

> 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. 

Yeah, but if it is already available in a separate module, it's even easier. 
on the other hand, packing a new KDE release isn't much more difficult
either, because it doesn't change in any way. Anyway, there is not that
often a new KDE release. Gnome is released almost every week, KDE only about
twice a year I guess. So even if it would be a _little_ more work for a
release, it should still be considered imho. 

> Taj 
> already wrote his cvs2pack script quite some time ago. This could even be 
> automated by monitoring version.h in a module's subdirs. 

so every commit needs updating the version.h. You an me know that this is
never the case (even ChangeLog's are normally not updated in KDE CVS). 

> 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.

such highly "intelligent" scripts are likely to break. Is there anybody who
has nothing better to do than sit there and browse the script logs to see if
something has gone crazy again? I maintain such scripts for another project
I work on and I can only repeat myself, that it's a whole mess and the time
spend for such stuff could be better spend in doing something useful. 

IMHO much too complicated. 

> The seperation into distinct configure.in.in files was a first measure to 
> have a better modularity. 

Exactly. And now I think we should start benefiting from it, otherwise the
whole stuff was just useless :-)


Dirk