Change release schedule 4.2 and schedule for 4.3

[Cornelius Schumacher]

On Wednesday 10 September 2008 02:35:53 Mauricio Piacentini wrote:
>
> Agreed, but how to force them to fix the bugs?

There is no way we can force developers to do anything. But we can try to make 
it easy and rewarding to do so.

> 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.

Yes, that certainly would help.

> 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?

Agreed.

> In an ideal world, we should be killing bugs as they are spotted, 
> and not only when the release is near.

Introducing new features always will also introduce no bugs, so even when bugs 
are killed when spotted, the overall stability can only be improved by having 
something like a freeze which prevents introduction of new bugs (and as a 
prerequisite introduction of new features).

> 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 :)

You know, what is said about throwing more developers on a project ;-)

-- 
Cornelius Schumacher <schumacher at kde.org>