policy change related to kdelibs snapshots

[Adam Treat]

On Monday 10 July 2006 4:22 am, Thomas Zander wrote:
> On Monday 10 July 2006 03:42, Benjamin Meyer wrote:
> > Why not simply drop the snapshot libs?  Any major changes should have
> > their own branch like liveui current has.  When big changes are
> > intigrated it can be announced ahead of time that things will be broken
> > for a day or two (some porting and testing should have already been
> > done).  For any minor changes, the guys who commit to libs should port
> > the rest of kde first.
>
> I (as a KWord developer) am firmly against dropping the libs-snapshot,
> even in the way you suggest.
> KOffice is on a tight schedule as is and forcing me to recompile kdelibs
> kdepimlibs and koffice so often will not only take the fun out of
> hacking.
>
> Updating all the packages above and compiling them takes about 3 hours.
> Thanks to cmake the mere chance of a CMakeLists.txt file in a
> koffice/libs will force all libs to relink, for example.
> Babysitting a compile for 3 hours (which assumes a 2Ghz machine, which is
> not near standard) before you can start working is a sure thing to lose
> about 90% of the app developers, I suspect.
>
> That and we can't explain it to Google why their SoC students stopped
> being productive all of a sudden. :)

I don't understand why this is so hard.  If you are worried about recompiling 
because of a kdelibs change, then just don't svn up...

That way each application and assorted group of developers can decide for 
themselves which revision to port to and when to update their 'snapshot'.  
All the developers of KOffice for instance can work on porting against a 
particular revision and then when things are settled or they have some time 
they can decide to update and port to a new revision.

Adam