Akademy Redux: Release Team Members Propose New Development Process (KDE.News)

We went from 1 release dude before KDE 4 to a team of probably a dozen or so individuals, each
with a part of the stack to look after, and a few central coordinators. So I think the KDE people
have certainly learned this lesson as well.

> When the Debian release team got serious about drawing lines and making
> the freeze a real freeze

... which is something we've nearly always done in KDE. The major exception was 4.0 when there
were lib changes happening way too close to release that caused last-month havoc, for instance.
4.1 was back to the usual freeze-is-a-real-freeze-no-we-aren't-joking of the last 10 years.

so .. that said:

> If KDE's new release process is going to rely on developers "discipline", well... good luck.

We rely on discipline now as it is. That discipline is guided by closing down the entire dev tree,
however. This doesn't particularly work very well anymore ... as an example, in Plasma we had
numerous development branches with major features going on during the 4.1 freeze. When 4.2
opened, huge numbers of features got merged in that had been artificially kept out until trunk
was unfrozen. Conversely, when 4.1 went to freeze, a whole bunch of features also poured in so we
could "get those features in" with the idea that we'd stabilize them in the remaining two months.
Even then, I committed the sin of adding a non-trivial feature during the freeze (moving widgets in
the panel). All of this puts my teeth on edge, but the current model actually encourages this
"lack" of discipline.

With the proposed system, we can have a main plasma development branch with all those non-
trivial-feature-branches hanging off of that. Development can now happen in 2-4 week cycles
where new features go in, things are tested, and then merged into trunk. Most people will follow
trunk and be able to catch the bugs we miss, but will be shielded from the worst of them. This
means trunk will be more reliable for people than it is now, and therefore safer to use daily.

This past week, for instance, the taskbar was broken for maybe 3/4ths of a day such that new
windows launched after the taskbar widget started wouldn't show up in it. Not the end of the
world, and fixed fairly quickly, but if you get caught updating during those 8-10 hours .. ugh! And
people did: we got bug reports about this one (it's nice that we have non-contributing users
following so closely).

Now, had we been using a dev-merged-to-trunk-every-N-week-cycle only the Plasma developers
would've been bitten. And of course, we noticed it as well all on our own. Hard not to. =)

Doing these cycles of merge into dev, test, merge into trunk, repeat just doesn't work right now
because (besides svn's annoying merging; though that's gotten better with 1.5) we have this 2
month void where we aren't *allowed* to do any feature development. This leads to the binge-and-
branch scenario described earlier.

The question is: can we get people to run the stable branches? With this model, the stable
branches should be even more reliable than they are now, and right now we have a lot of people
who *only* use the stable branch (mostly application developers). So as long as we don't harm
that, we should be ok there as well.

That said, there are questions remaining to be answered, but a change is not going to happen
tomorrow so we have time to work things out.

(Is the point that this is forking *and publishing the fork* that's made
easy?)