policy change related to kdelibs snapshots

[Stephan Kulow]

Am Montag, 10. Juli 2006 18:21 schrieb Dirk Mueller:
> On Monday 10 July 2006 17:12, Cornelius Schumacher wrote:
> > I'm not sure, if you meant it this way, but I think it would be good to
> > have bleedingedge for all modules including kdelibs.
>
> I'm against that. if there is big restructuring going on (e.g. LiveUI), it
> should happen in its own branch. If its smaller stuff, it should happen in
> trunk. Those with the powerful build clusters (and the committer himself)
> will be able to fix the failures.
>
> > This way new features
> > and API changes can be developed without affecting application developers
> > who prefer to work on a stable version of kdelibs.
>
> The major pain that was caused by the snapshotting (and the
> instability/porting errors) in trunk is that there were a lot of unrelated
> changes bundled together and suddenly being flood over all of the tree due
> to a snapshot update. This caused a lot of hectic fixes done by script
> porting and the resulting instability.
>
> Doing so in trunk would make things at least somewhat easier to track
> again, because one doesn't have to remember what particular API changed
> almost two weeks ago in which way.

Yes, but that doesn't mean it can't happen in a parallel branch, which is then 
merged in bigger chunks to limit the times you have to recompile to
get an uptodate trunk. 

Greetings, Stephan