Change release schedule 4.2 and schedule for 4.3

[Cornelius Schumacher]

On Tuesday 09 September 2008 19:47:30 Aaron J. Seigo wrote:
>
> this feast/famine cycle is driven by being allowed to work on features in
> certain times but not others. this doesn't actually stop feature
> development, though, it just diverts it elsewhere.

That's actually a good thing. When approaching a release feature development 
has no place in the branch which is going to be released.

Of course we should make it easy to integrate feature development which goes 
on in parallel to a release period, and of course we also need to make sure 
that there is still enough focus on the release and not all development 
diverts elsewhere.

> while disallowing feature work may seem to be a good thing, the idea being
> to focus people on bugs, it turns out that it actually makes the code base
> wobble in stability a lot during feature feasts.

Introducing new features always will affect stability, no matter how often and 
when it's done.

Feature peaks like we see them now can have very negative effects on stability 
as they in some cases can change too much different things at once. But a 
continuous flow of incoming features can also have very negative effects, as 
it also means a continuous flow of incoming bugs, which might make it hard to 
stabilize code, even if the bugs are not really related, but just make it 
more difficult to work on the code.

> bug/stability doesn't 
> happen due to feature freeze, it happens most or less when i post a mail to
> the list saying "ok! let's see if we can kill N bugs!" or something similar
> to that. i do this in response to upcoming releases. if i don't issue the
> call, the bug fixing pace seems to remain about constant regardless of the
> period of the devel cycle.

That's an important aspect. Imposing rules or disallowing certain actions 
might be necessary in some cases, but it doesn't get stabilizing and bug 
fixing done. For that we need to create an atmosphere which encourages that, 
e.g. by team efforts to address bugs.

> now, i'd prefer to see it go:

> * Spring branches are merged when features are "ready" into a Summer

> * Summer goes through rapid cycles of "1-2 weeks of devel and Spring

> * Autumn branch should be in a relatively good situation due to the Summer

> * When KDE branches for release (call this the Winter branch), we will put

I really like the terminology. That's a very suggestive way to describe what 
branch is used for what purpose. I suppose that helps a lot with getting 
people to understand which branch is meant for what, which is a very 
important point in the development process. Communication is one of the most 
important aspects of all this.

> with the proposed system, we'd have:
>
> * Plasma team on Summer with some Spring mixed in here and there, feeding
> into Autumn. We'd catch as much or more of the issues ourselves.

So this would be equivalent to the current work or private branches (Spring), 
and a new branch (Summer) which collects all the new code, probably per 
subteam.

This is the element I would see as the most beneficial of the season branches 
approach. We currently don't have a very well defined and practical approach 
to work on bigger changes in a coordinated way without affecting other 
developers.

But are we able to maintain four branches in parallel? With a better suited 
version control system this might be possible, but it probably still requires 
more effort than we have now, and it certainly will blur the focus of many 
developers.

That's why I really would like to maintain some release rhythm for the overall 
development. It would provide focus to our developers and make a good use of 
our rather limited resources. So when approaching a release the focus would 
move from Summer to Autumn and finally to Winter. We could still accommodate 
people working on new features in Spring branches, but the overall attention 
should be on the work which results in the concrete next release, which in 
the end is all that matters.

> * KDE core development community on Autumn, catching what we miss.

This would be equivalent to the current SVN trunk.

> * KDE application developers on Winter branches, helping additional
> stability testing.

This would be equivalent to the current stable branches which are branched off 
trunk when a release is done.

> * KDE users using released version.

This obviously wouldn't change.

> the goal would be to get defects reported and fixed before hitting released
> versions; the difference between the two approaches boils down to:
>
> * a more even pace for the Plasma team; less feast/famine cycles due to
> artificial constraints, and hopefully a higher stability baseline due to
> that.

I still don't see why that would lead to higher stability. As I said above, it 
can work, but it can also fails. I have seen both cases.

> * Plasma team won't have to worry about developer sprints matching up with
> release schedules quite so much

With Spring and Summer branches this seems to be no problem. I remember doing 
something like that with a "osnabrueck" branch in KDE PIM as well.

> * people following trunk/ get bitten less often with "zero day" bugs due to
> new feature commits

This would be the effect of the new Summer branch. If there actually are 
enough developers caring about Summer, this would probably work.

> svn will likely _not_ work for the proposed situation very well, a
> centralized git system should work rather well however.

Yes. git makes handling multiple branches much more easy than svn. Of course 
it is also possible to do this in svn, but it requires more work.

-- 
Cornelius Schumacher <schumacher at kde.org>