Change release schedule 4.2 and schedule for 4.3

[Mauricio Piacentini]

Speaking from my experience in KDE Games, you can not force someone to 
participate in the stabilization phase anyway. What I see happening is 
that we end up having a smaller window of opportunity for new 
development to occur. This (I think) can be better handled with a DVCS 
that is friendlier to branches and local work. I have no experience with 
git, but it appears to foot this bill from what I have heard. What I 
know for a fact is that very few people bother to branch in SVN right 
now: we simply wait until things are unfrozen to start working on new 
features, that is what happens. And if someone is busy by the time the 
trunk is open the development does not happen, it is simple as that.

As a comparison, in the time the trunk was "opened" we were incredibly 
productive, just before 4.0. I do think we can regain that drive with 
the "always summer in trunk" proposal by Dirk and Sebastian. At least I 
think we should try something different, as the current centralized and 
serialized mode is apparently hampering development at least on some 
areas of the project.

The freeze periods really do impact our module negatively, from looking 
at what happened before 4.0 and 4.1. Number of commits is much lower and 
the community disperses for 2 or 3 months. We stop working on features 
that we think will not be completed in time, or worse, do not start 
working on them at all. In our case this happens because probably there 
are not many showstopper bugs, so freeze period equals no development 
activity for several people in our module, as branching is expensive in SVN.

I also see that the ones that work in bugfixing and stabilization are 
not necessarily the ones that work on new features, so I fail to see how 
we can get worse compared with what we have now. The question of 
stability of code can not be improved I think by forcing people to stop 
working on trunk for a given period of time. In fact, by giving people 
the freedom to commit at anytime we will probably avoid the rush of 
half-finished features just before the freeze date, and this might even 
improve the quality and stability, who knows. This tie between the 
development schedule and the release schedule appears to be something 
not optimal, and affects the community building portion of the project 
as well. So why not try something different, at least for post-4.2, and 
see what happens?

Regards,
Mauricio Piacentini