Change release schedule 4.2 and schedule for 4.3

[Tom Albers]

At Tuesday 09 September 2008 20:54, you wrote:
> 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

I hate to fload the mailinglist. But I agree completely with Boudewijn. I think these are valid concerns and I don't really see this git/always-summer be a magic solution to our problems.

As long as our users use another branch than what we developers use, I'm likely to vote against that plan. I think the only way to make awesome releases is to actually use what the users use. So you get annoyed with the same bugs at the same time (or rather a bit earlier). 

Best.

Toma