Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Tuesday 09 September 2008, Cornelius Schumacher wrote:
> 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.

it's not about ignoring the release schedule, it's about not requiring the 
development schedule to follow the release schedule. some projects (many, 
perhaps, even) will continue to follow the release schedule as their 
development schedule out of convenience. others will opt for a differen approah 
(see the leeeengthy plan laid out below for plasma)

> But maybe we don't need the same schedule for all subprojects. If a

yes, i think that's actually a given.

> 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.

this already happens, of course =)

i think it would have been great if, e.g., the kdevelop module could have 
simply ignored the freeze cycles for 4.0 and 4.1, gaining an extra 4 months of 
available mainline development time. they weren't going to make those releases 
anyways, so why bother? with the Always Summer approach, kdevelop could 
continue have been worked on constantly in their Summer branch and merged into 
the Autumn branch at their own pace, freezes be damned. now that they'll hit 
4.2, they would probably adjust back to the global rhythm.

it feels like a much more natural sort of flexibility, one we can only 
approximate with a fair amount of pain and with much explanation to others 
using branches in svn or external git repositories.

> > 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.

what follows is all pretty Plasma specific, though not unique to Plasma. it 
won't hold for all projects in KDE, however:

right now it tends to go:

Unfreeze (start of new dev cycle): Feature (and bug) feast! all kinds of 
features get merged into trunk that were developed in the past N months but 
were held out until this point due to the feature freeze

Devel cycle: emphasis on feature development to get as much in during open 
season, stabilization of features merged in at start.

Just prior to freeze: Feature (and bug) feast! lots of features get merged in 
from branches to "beat the freeze"

Freeze period: Feature (and bug) famine! sort it all out, stabilize things in 
trunk; new feature devel continues on in branches (both svn and git; i can't 
force people to stop working on their features; we do close lots of bugs 
anyways during this period)

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.

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. 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.

so the global KDE dev cycle isn't enough: we have to translate that schedule 
into the Plasma contributor's lives. it's especially hard given that most of 
our people don't do work on plasma every day, and so have sporadic bursts of 
input that aren't schedulable.

now, i'd prefer to see it go:

* Feature development happens in "hot" branches; let's call them Spring 
branches (new growth =)

* Spring branches are merged when features are "ready" into a Summer branch. 
devel that doesn't require its own branch (small scope changes) happens in 
this merge branch as well. development may continue in Summer regardless of 
what's going on. anyone can create a Spring branch at any time, new 
development can happen in Summer at any time; this combination replaces the 
need for playground/.

* Summer goes through rapid cycles of "1-2 weeks of devel and Spring merges, 
pause, up to one week of stabilization or until we're happy with it" at which 
point it merges into KDE's mainline, or "Autumn", branch. this is actually 
pretty close to what we already do in the middle parts of the feature devel 
part of a cycle.

* Autumn branch should be in a relatively good situation due to the Summer 
cycle. it won't be perfect, but it'll be better than Spring or Summer  
branches. all other KDE developers would likely be using the Autumn branch, 
and would be at most 2-3 weeks behind Plasma developers, though usually less; 
this means bugs they notice are likely to still be useful to the Plasma team. 
as nearly all Plasma devel is done by people who contribute regularly to 
Plasma and would therefore be following the Summer branch, loss of patches due 
to small lag would be near-zero.

* When KDE branches for release (call this the Winter branch), we will put an 
extra focus on bug fixing as we normally do but feature development can 
continue in Spring and Summer. bug fixes in Summer will be merge into Winter, 
just as we backport fixes now from trunk to 4.1 only a bit more aggressively 
pre-release (betas and RCs).

the question becomes, who will be TESTING all this code, right? the goal is to 
squash problems before they become part of a release, with the fallback goal 
to fix problems that are caught after a release in the stable branch.

well, right now we have the following with Plasma:

* Plasma team is always on trunk, with lots of playground stuff, other branches 
and uncommitted local features. We catch the majority of bugs introduced into 
the code.

* KDE core development community is on straight trunk, and catch significant 
numbers of issues that arise.

* KDE application developers are on 4.1 (example: working with KTorrent's 
plasma stuff recently, i had to keep patches 4.1 compatible as the KTorrent 
team understandably develops against the stable branch)

* KDE users are mostly on released versions: 4.1.1, 4.1.0 or 4.0.5 releases.

there is some cross over (e.g. some users on stable or even trunk; some app 
devs on trunk; occassionally we'll get plasma contributions based on stable 
branch; etc)

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.

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

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

* KDE users using released version.

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.

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

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

* we'd need to get people following Winter branches to bump up to the new 
Winter branch earlier than they do now; right now they do this mostly right 
around the time of release when the branch is made, but we'd want them to 
switch when the branch is made closer to the beta/rc cycle.

otherwise, it's rather similar.

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

and again, this is all from the plasma perspective; in particular, plasma:

* has a large vibrant contributor team

* has at least one full time contributor on it

* is highly modular

* is developed at a very rapid pace

any of the above could change in the future, and that may shift things yet 
again for us. at least with the "always Summer" approach we could shift back 
to how things are now really quite easily, while we are simply stuck with the 
current system no matter what.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080909/ac36cbed/attachment.sig>