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

List:       kde-core-devel
Subject:    Re: empath
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-01-06 11:36:29
[Download RAW message or body]



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

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

Wouldn't that break cvsup?

(AFAIK it does)

Ciao,
 Simon

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

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