kdebase + kdelibs head

[David Faure]

On Tuesday 21 March 2006 20:34, Scott Wheeler wrote:
> On Tuesday 21 March 2006 20:18, David Faure wrote:
> > Because it takes time to test the new stuff, and currently we have ~ 2
> > weeks to test new kdelibs code. With "break it all on Mondays" there would
> > be no testing at all before the porting of the app code [...]
> 
> Test how?  Are you porting stuff over to the branch to see how apps respond to 
> the changes?  (I'm actually curious -- for the probably-kdelibs-at-some-point 
> classes that I've been hacking on here I always end up needing an application 
> to test them with and well, have written a couple.)

Testing by: porting the rest of kdelibs to the API change, writing unit tests,
and then using higher level test programs (e.g. if you change KIO you can use
the kfiledialog test program to test it, etc.).

> > Such a policy would actually prevent kdelibs development from happening at
> > all, at this point. 
> 
> Fair enough.  I don't doubt it would slow those working on it down a bit, but 
> it would probably also get a few more people hacking on it.  I suppose the 
> interesting point is figuring out when one outweighs the other.  Any rough 
> guesstimations on how far out such would be?

The amount of major changes to kdelibs this week tells me that we are in
a better shape than before in terms of "people hacking on kdelibs".
And I don't think we'd get more people working on kdelibs if 6 days out of 7
they would be prevented from making API changes.

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