User: Password:
|
|
Subscribe / Log in / New account

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

KDE.News covers some changes that are planned for the KDE development process. "At Akademy 2008, KDE Release Team members Sebastian Kügler and Dirk Müller discussed the future of KDE's development process. Describing the challenges KDE faces and proposing some solutions, they spawned a lot of discussion. Read on for a summary of what has been said and done around this topic at Akademy. Our current development model has served us for over 10 years now. We did a transition to Subversion some years ago, and we now use CMake, but basically we still work like we did a long time ago: only some tools have changed slightly. But times are changing."
(Log in to post comments)

Discipline

Posted Aug 28, 2008 23:42 UTC (Thu) by jordi (subscriber, #14325) [Link]

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

Debian improved its release process when it let its Release Team grow in number so they could be effective in "disciplining" the rest. Everyone, and that includes package maintainers in Debian or program authors in KDE, thinks "this tiny little feature is cool enought to have in the next release, and it surely can't break anything else. Right?".

When the Debian release team got serious about drawing lines and making the freeze a real freeze, things started going significat better. Sure, there were delays with etch, and looking at the RC bug count it doesn't look like lenny will be released next month, but compare any recent release with potato or woody. I think GNOME's experience is worth looking at too.

Discipline

Posted Aug 29, 2008 1:45 UTC (Fri) by aseigo (guest, #18394) [Link]

> when it let its Release Team grow in number

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.

new tools to attract developers

Posted Aug 29, 2008 11:18 UTC (Fri) by jordip (guest, #47356) [Link]

If Git is to be used, I _strongly_ recommend taking a look to:

http://www.github.com.

It is a Git hosting service with social networking bits on it.
Also, contribute and fork one owns private branch is as easy as click the "fork" button. Make improving software not interesting but something one can't stop doing!

new tools to attract developers

Posted Aug 29, 2008 12:44 UTC (Fri) by nix (subscriber, #2304) [Link]

If it's git, forking is anyway as easy as cloning (indeed it's the same
operation).

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

new tools to attract developers

Posted Aug 30, 2008 11:18 UTC (Sat) by sebas (subscriber, #51660) [Link]

github is certainly interesting, but as it's not Free software, we're
looking into alternatives that provide similar functionality. Gitorious is
interesting in that regard. Surely, those tools (and a hopefully more
streamlined review process that becomes possible strongly speak for using
it.

new tools to attract developers

Posted Aug 30, 2008 12:53 UTC (Sat) by jordip (guest, #47356) [Link]

Yes, I also put the link to github on the dot and someone already made me realize that github is not opensource.
Gitorious seems to be similar in philosophy and I am sure that can be improved to make it a good tool for KDE.
It will be a lot of work to change to the new model (integrate to bug reporting system,etc) but I absolutely support you on this move.


Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds