policy change related to kdelibs snapshots

[David Faure]

On Monday 10 July 2006 02:19, Benjamin Reed wrote:
> On 7/9/06, Benjamin Meyer <ben at meyerhome.net> 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.
> 
> Yeah, this is how we do development where I work and it's very
> effective.  Trunk is always compilable, bugfixes and minor changes can
> go in, but anything sweeping happens in a "feature branch" before
> getting merged.

That's how kde development -usually- works .... when the kdelibs API isn't 
changing all the time.

I doubt that the Benjamins (both of you) are developing applications - right?
It's the application developers that need a stable libs to work with, and
that's what kdelibs4 snapshot offers. The only problem was that this made
kdelibs developers make unrealistic changes, and that's what "more use of
bleeding edge" (by kdelibs developers, anyone else doesn't need to care)
solves.

Remember how Reinhold described the problem, that when he has time to
work on kdepim he first needs to make it compile. With a kdepim that uses
kdelibs snapshot we can make sure that it always compiles, especially if
snapshot updates don't break things anymore, given that the porting will
have already been done (in bleedingedge).

So I'm in favor of Stephan's suggestion. We just have to hope that the requirement
to port bleedingedge doesn't make too many people drop the idea of improving
kdelibs - but on other hand doing untested improvements is never good.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).