Change release schedule 4.2 and schedule for 4.3

[Boudewijn Rempt]

On Tue, 9 Sep 2008, Thiago Macieira wrote:

> On Terça 09 Setembro 2008 15:23:43 Torsten Rahn wrote:
> > The proposed always-summer-in-trunk model rather is an "opt-in" model which
> > allows the group to become much more loosely bound "together". "Opting in"
> > would require to take action and make a decision (which people try to avoid
> > if possible)
> 
> The current model is already an opt-in one.
> 
> If someone doesn't want to participate in the stabilisation phase, all he has 
> to do is stop committing.

Sure: but your reasoning is pretty specious. If one stops committing at all, or only
work in a branch for three months, it feels bad. As if you've placed yourself outside
the community. Which, in fact, you have.

If, on the other hand, you keep coding cool stuff and, while never really making it
available to users, still making it somewhat available, you can blog about it and feel
good and a front-runner who's taking KDE places. While you're still relying on others
to do the dirty work of bringing your stuff up to scratch and making it releasable.

Right now, having the boring work, i.e., making it into a release, depends on you also
participating in the stabilistation phase, trunk-is-always open rewards the opposite: 
have fun. do cool stuff, never care about integration or stabilisation, just blog and be
famous.

> He doesn't have to remain idle for the 3 months when trunk is frozen. He can 
> create branches and work there. Or keep the code to himself in a local DVCS 
> repository (svk or git work just fine for that).

Hard facts are needed with this kind of argument, the kind of facts Paul Adams can provide: 
how many people stop committing and start working in branches during soft and hard feature
freeze. Does the commit rate drop off, and what happes to the bug rate?

> The point of "it's always Summer in trunk" is to make sure that the 
> development stays in trunk and those people don't go away for 3 months because 
> it's frozen.

Sounds great. But I don't believe it will work that way. Always summer in trunk will,
I predict, result in a big mess and nobody but the paid help doing stabilisationand
release work. Development in trunk is a Bad Thing if diverts any attention from releasing. 
No feature is worth a dime if it means a feature that got implementer earlier gets
released later.

Boudewijn