Change release schedule 4.2 and schedule for 4.3

[Cornelius Schumacher]

On Monday 08 September 2008 21:13:53 Aaron J. Seigo wrote:
>
> the idea that was floated is, essentially, to allow release engineering to
> happen alongside development without forcing one schedule to mimic the
> other 100%.

The problem with that approach is that it separates (unstable) feature 
development and stabilization (and releasing), so that we might get in the 
situation where people working on new features are not contributing to 
stabilization.

This is particularly bad as it has a negative dynamic. The less people are 
working on a stable branch, the more difficult and frustrating it gets, 
especially if you have to fix bugs of code where the original developer 
doesn't contribute to the stabilization effort, which leads to even less 
people working on the branch causing more frustration and so on.

So by separating stabilizing and releasing from main development we run into 
the danger of cutting off the branch we are sitting on.

> so either the 4.2 release schedule fits PIMsters, or the PIMsters work in
> branches, ignore the release schedule and just merge into trunk when it
> makes sense.
>
> the latter is what is being suggested.

For me it's not a question that we need a release schedule and we need some 
kind of rhythm of feature development and stabilization. We can't go without 
freeze periods. Ignoring the release schedule sounds like a very dangerous 
approach.

But maybe we don't need the same schedule for all subprojects. If a subproject 
has special needs and needs a different schedule it might make sense to for 
example skip a release or even do a separate release.

> for the Plasma team, it would remove the cause of the "two clump"
> phenomenon where we have two major drops of features each cycle: once at
> the start of a dev cycle, and again right before feature freeze. the result
> is a lot of stabilization efforts in between that shouldn't be necessary.
> if we are allowed to work in trunk/ as a semi-frozen branch with more
> active work in one or more "hot" branches sync'd over every 1-3 weeks
> without break, things would be a lot smoother.

Why would that be smoother? Stabilization is not optional, you need it in any 
case.

> bottom line: if we do disentangle release-from-development-cycles, release
> timing and quality need to at least match what we're doing now as a bare
> minimum.

Yes, changing our release process only makes sense if it brings significant 
improvement. I wonder how we can measure release quality, though.

> > Summer feelings are nice, but we are working on software used by millions
> > of users who are looking forward to bug fixes and new features after all,
> > not on the KDE version of Duke Nukem Forever.
>
> indeed. thankfully that's not the proposal that was made.

Yes.

-- 
Cornelius Schumacher <schumacher at kde.org>