Change release schedule 4.2 and schedule for 4.3

Mauricio Piacentini piacentini at
Wed Sep 10 01:35:53 BST 2008

Cornelius Schumacher wrote:
> This is one of the core problems we have to address. It's not a healthy 
> separation, if people don't care about fixing the bugs of their own code, but 
> let others do it.

Agreed, but how to force them to fix the bugs? My reasoning is that 
ideally we would need to get better at avoiding the bugs getting in 
trunk, and this is where a different (descentralized) source code 
management tool could help, by allowing easier review of patches and 
development of features in parallel. But this is not the only action 
that could help us "lock the bugs out": I think that one point mentioned 
by Thiago (the importance of testing) is what we really need, at least 
in KDE Games. We talked about this during last Akademy, at our BoF. 
Currently we rely on the game author to test new features, basically, 
and on the goodwill of very few peers. I do not have an answer for how 
we could improve this, but I feel that a system that allows easier peer 
review and cherry pick of features BEFORE they get in trunk could help 
us improve the quality. These better tools for collaborative reviewing 
of patches and merging could also help us run bug-killing marathons, 
perhaps. But none of this really depends on the release schedule, does 
it? In an ideal world, we should be killing bugs as they are spotted, 
and not only when the release is near.

Mauricio Piacentini

PS: of couse in this ideal world we would also be all paid to work on Qt 
24x7, and we would have 10x the number of developers we have now, all 
very much interested in following bugzilla :)

More information about the kde-core-devel mailing list