During the Desktop Summit in Berlin, we had a session in which we had a good look at how KDE’s release team performs, which points we can improve on, how, and who will implement these changes. For example:
- Make our output more predictable and thus downstreams’ lives easier
- Reduce the risk of something going wrong, the bus number problem
- Make our work more efficient
Let’s take a step back first, though.
A bit of history: from Coolo & Dirk to TWG to Release Team
In KDE 3, Coolo and Dirk managed KDE’s releases. When KDE4 was started, we also wanted to promote this in a more suitable fashion, we started doing more proactive PR work, and generally improved our communication to our users (potential or not). In 2005, the Technical Working Group was conceived, which was meant to handle the releases of KDE4. The Technical Working Group didn’t quite work out since it didn’t bring the structural changes we needed in order to release KDE4. In late 2006 we we decided that it didn’t work, disbanded the TWG and conceived the release team, a self-organized team of volunteers. Conceptually, the release team started as a place for people to go who wanted to make releases happen. We found module maintainers for our released modules who would coordinate towards the app teams and, and a few core people who know how all that stuff works to put things together. We got our release process on the rails again. Interestingly, the release team is very informal, we never ended up appointing anyone release manager, or end-responsible — it has also never been necessary, it seems. Lesson here: shared responsibility works well for us.
A quick unscientific count of the whole KDE 4 series (including pre-releases) brought me to 88 releases done by the release team in its current form.
Git migration and tarball layout
During the migration of our source code repositories to Git, we had a bit of trouble keeping up with splitting of our released modules. This has caused a bit of grief among some packagers, but we’ve sat down together a few times and worked out good solutions for these problems. The Git migration meant that we’d split out repositories such as kdegraphics, but shipping a different set of tarballs also means that packagers have to adjust their scripts, spec files and so on. The Git migration was spread out over a period, meaning that we basically ended up with shifting tarball layouts across patch-level releases, which unintentionally added a bit of work across those releases. Thanks to the feedback from packagers (especially Slackware has helped us a lot there), we were able to address these things, before and during the desktop summit and have become much more aware that the tarball layout is for us essentially a public interface which should be kept stable, and not change without good reasons and communication to those who are affected by it. This will be done as changes to the release scripts, which combine git repos into tarballs.
Release Team BoF
As I mentioned, during Desktop Summit, we used the opportunity to talk about these problems and find solutions to them in a BoF (Birds-of-a-feather) session. About 12 people got together to work on this, including downstream participants such as Slackware, openSUSE, Gentoo, MeeGo, Balsam and people from the release team, build system knowledgables and GNOME’s release team. A group with different angles but a shared goal. I think collaboration has come a long way, seeing that we share processes and experiences across many groups.
The BoF session was kicked off by a discussion wether we want to change our release rythm. People were pretty happy with our time-based, 6-monthly releases, so we quickly decided to keep these. We thought about reducing the number of patch-level releases, which might make sense since we’re in much calmer water than when we started with this rythm at 4.0. There are — unsurprisingly a lot less critical bugfixes now than back in 2008. Our users seem to be really happy with our cadence, so we decided to reduce the work with these releases a bit more, but to keep our monthly updates — no changes there.
Release Team Tweaks
So what did we come up with? The following list of items should give you a good idea of that, but please keep in mind that we haven’t nailed everything down completely, and that it’s a bit of work on progress. The things left to do aren’t that horrible, so I suppose I won’t take long until we have adopted these tweaks to our processes, and that the results become visible. I’ll put this onto the Wiki once I’ve dealt with the post Desktop Summit lack of sleep. :)
- Human backup strategy:: We’ve checked with each other who jumps in. Once in a while we’ll have the backup person take over a release, so we actually make sure that we not only think we’re safe, but that we actually are. We’ve started approaching people who we think have the responsibility, trust and skills to backup the release team.
- More parts to be automated: Script more parts of the release notes,our patch-level releases still involve “monkey work” to a certain degree. This involves some easy changes to the PHP scripts will help us we attempt to maintain consistency across release notes.
- More predictable tarball layout: The tarball layout will be kept in place for 4.x, Frameworks 5.0 will obviously bring changes to the tarball layouts, which will happen as a one-time change.
- More rythm to the community by communicating more often where we are in our cycle. This will most likely happen in the form of reminders to email lists such as kde-core-devel, release-team, kde-devel.
- Promo Team does release notes: The promo team is the right place to create release material, Carl offered to coordinate this on the kde-promo side.
I think that these points bring a nice set of improvements to our current release process and prepare the way to the eventual release of the KDE Frameworks 5 — we came up with a strategy to facilitate the modularization in the structure of especially our development frameworks. One that works for us and our downstreams.