Ubuntu Maintenance Work

I promised myself I would blog more about the work I do on Ubuntu, but I’ve not done anything glamorous enough recently to talk about. So instead I thought it might be interesting to give a top level view at some of the behind-the-scenes maintenance work that an Ubuntu developer like me gets up to.

Most Ubuntu developers will already know this stuff, but for those of you who are curious what kind of high-rolling life we lead, read on.

+1 Team

I recently came off a month rotation on Ubuntu’s +1 Team. This is a shifting group of people that try to keep all packages buildable and installable.

There are two very helpful web reports for this. The FTBFS report (fails to build from source) and the NBS report (not built from source).

When a package can’t be compiled from source (due to changes in libraries it uses, changes in compilers, incompatibility with less common architectures like ARM, etc.), it shows up on the FTBFS report. Typical cases are a missing build dependency or needing a newer version of a library.

The NBS report is for packages that we have to keep in the archive because some other package needs them, but we no longer have the source package in the archive to match it. For example, if libfoo1 becomes libfoo2, the foo source package no longer builds libfoo1, but we still need that package in the archive until all other packages use libfoo2. Usually, this is as simple as a rebuild of affected packages. When there are no more users of libfoo1, an archive admin can drop it from the archive.

This team always likes help, if you’re interested!

MIR Team

The MIR Team is the team responsible for approving packages that need to enter main, usually in order to be included on the Desktop or Server CDs. This additionally means that Canonical is on the hook for support of the package.

This review is largely focused on making sure that the package will be well maintained. That it doesn’t have a terrible history of security flaws. That it doesn’t needlessly duplicate existing main packages (for example, we’d like to have as few XML parsers that the security team has to look after as possible).

This is a relatively small team, since these reviews don’t need to happen often.