Philipp is a Debian developer since 2005 and a member of the release team since 2008. Since he took the responsibility of Stable Release Manager, the process has evolved for the best. I asked him to explain how the release team decides what’s fit for stable or not.

His work on the buildd infrastructure is also admirable but I’ll let him describe that. My questions are in bold, the rest is by Philipp.

Who are you?

I’m a 24 year old Computer Science student, living in Karlsruhe, Germany. As a student assistant I’m currently in two jobs: one is taking care of getting our university IPv6 network in shape, or rather generally getting fringe technologies into the network. The second is taking care of a s390x machine in the basement which my faculty got sponsored recently. In my spare time I tend my Debian duties and I’m active in the student council (Fachschaft) as a sys-admin, software developer and until recently as treasurer.

I got accepted as a Debian Developer in 2005. I’m only really active since I was invited to join the Release Team in early 2008 after I contributed rewrites of some scripts that got lost in a disk crash of ftp-master. In late 2008 I also took on wanna-build/buildd duties.

What’s your notable achievement within Debian?

For one I worked on the deployment of a single buildd/sbuild combination over all of our buildds and I rebased it on the sbuild in the archive several times already. All buildds basically look the same on all architectures, with only few variations. The chroots are now also created in a mostly predictable manner.

Then we finally got build autosigning after years of constant poking. However the policy decision to allow it was made by the ftp-masters anyway, for which I’m grateful, as it eases the workload of the buildd maintainers, the Security Team and the Release Team quite a bit.

On the release side there’s the integration of volatile into the proper structures of Debian. But there I’m guilty for choosing the bad name squeeze-updates is, in comparision with security’s squeeze/updates. Let’s see if we can improve that for wheezy.

The policy for stable updates have changed over time. Can you summarize what kind of updates are allowed nowadays?

All the changes that were made to the policy were driven by the aim to keep stable (and to some lesser degree oldstable) usable throughout its lifetime.

I have to admit that we got slightly more liberal in what we accept since I took over. The previous stable update policy included the fixes of critical bugs that break the system in interesting ways and security fixes. We also opened up the possibility of including important fixes for annoying bugs on a case-by-case basis.

The whole “don’t update that much” part of the stable release management is rooted in “let’s don’t change the behaviour of a running system” and “let’s have as few regressions as possible”. We currently try to counter that with a review process that only allows self-contained fixes that were tested in unstable first, if applicable.

In the future I’d also like to have a feedback process that includes the users of the packages to report problems more early. In fact that’s also why we now send calls for testing to debian-stable-announce one week in advance (see this mail as an example).

So stable is updated through point releases that happen roughly every two months for stable and roughly every four for oldstable. They are accompanied by announcements and new CD/DVD sets.

To be able to push some updates with less delay to our users and to avoid that they have to pick them from proposed-updates, there is stable-updates. The current policy for this suite is available in this post on debian-devel-announce. It boils down to everything urgent like tzdata, regression fixes and volatile packages. We noticed that some packages in stable just weren’t useful anymore when they got updated through volatile. Hence those are folded into stable, too. We also relaxed the rules a bit so that leaf packages like clive, that rely on external websites not to change their URLs, can be updated too.

If somebody wonders what happened to the “and a half” releases… Those were intended to mark the inclusion of new hardware support (mostly by including a co-installable new kernel version). This kind of flag point release is thankfully no longer needed because our marvellous kernel team now backports certain hardware drivers to the kernel version in stable. They have some trouble soliciting test feedback for them, though. It would be cool if more people using stable could respond to their calls for testing.

What are your plans for Debian Wheezy?

Luckily the wanna-build/buildd side isn’t much dependent on release cycles. The stable release management also just takes care of what gets dumped on them by the testing RMs. 😉

The near-term goals are certainly:

• getting d-i to use some development process in the archive that’s compatible with the normal flow of packages into testing and
• hopefully getting wanna-build to use a sane SQL layout and hence better performance

Apart from that my work is mainly squashing the bugs on buildd.debian.org for the wanna-build part, so if you want something fixed, you need to report it, I’m afraid.

You have several roles within Debian, in particular stable release manager and member of the wanna-build team. Which role do you enjoy more and why?

So the regular duties of the SRM, apart from setting up policies, are reviewing requests for uploads to proposed-updates, accepting them, chasing builds and scheduling point releases. It’s mainly steady work. As for the Release Team it’s working in a fabulous team where everyone’s doing an awesome job.

For me the wanna-build role is holding the things together and fixing up stuff that breaks while the world continues to evolve. And occassionally taking a stab at the ftp-masters. So rather… different.

My heart is probably siding with the buildd side because it’s infrastructure but release work is fun, too.

What’s the biggest problem of Debian?

Mainly that we’re not quick in picking up new technologies and that we got slow on innovation. Distro-wide changes are usually a very big effort to coordinate and to finally complete. I guess people should be able to push fixes for release goals more eagerly into the archive.

Also it seems to me that many DDs are actually disengaging from the release process, especially during the freeze but also before, which makes me a bit sad. However I’m still not sure how we could counter that. As we’re all volunteers you can’t suddenly make others love the idea of releasing something together, I guess.

Do you have wishes for Debian Wheezy?

It’s getting old, but there’s certainly multiarch. Also a usable Python 3 is something I’d really appreciate.

Is there someone in Debian that you admire for their contributions?

Peter Palfrader did an awesome job of getting a nicely working team together for DSA and got many tasks as automated as they are now. It’s a pleasure to work with them and setting up a new buildd is, for example, a real breeze. He also developed a sane archive snapshot service, kudos for that.

---

Thank you to Philipp for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.