Five build fixes a day

Colin Watson cjwatson at
Mon Sep 12 15:02:24 UTC 2011

We have 661 build failure bugs open right now:

The good news is that this is down from well over 700 yesterday, so we
are making progress.

The bad news is the build failure queue has been very long for ages, and
we haven't been doing anything consistently effective about it;
certainly some good people have been working on some failures, but the
queue has dominated the effort available to deal with it for a while
now.  As a result, we've had to exclude build failures from routine
consideration in release meetings and the like.  That was pragmatically
sensible (some of the binaries have been removed, the bulk of the bugs
are against universe [1], etc.), but it really can't go on.  Being able
to build your software reliably is one of the most fundamental tenets of
software engineering, and any good team assigns a high priority to
fixing build failures.

Right now, there's a small number of us cranking through the build
failure queue, but we have allowed this problem to build up far enough
over time that it's going to take a somewhat more concerted effort to
clear it.  On the upside, if we can get the queue down to zero or near
zero and keep it there, other things will be easier later: it won't be
as much effort to transition packages over to new libraries, users of
(particularly) non-i386 architectures won't have as many problems due to
build skew between i386 and other architectures, you won't find yourself
making a change only to be sidetracked off into fixing a lurking build
bug that's been hanging around for six months, or trying to make an
entire software stack build on some new architecture.

So: I am personally committing to upload fixes for *at least five build
failures per day*, Monday to Friday, until such time as I run out of
things I know or can teach myself how to fix.  My own experience is that
I can do this and still have plenty of time to deal with other things in
a working day.  If nine other people join me in this commitment, we
should be able to clear the queue in under three weeks.  Who's with me?

I'm expecting this to be mainly fairly experienced developers; fixing
build failures is good practice, but you probably don't have much time
to learn before Oneiric.  It probably isn't something to try if you're
brand new to Ubuntu development.  But if you've already got your feet
wet with Ubuntu package maintenance and want to try your hand at some of
this, then these links may help:

Please remember to forward patches to Debian and usertag them
appropriately (, and note the
usertags in as well).

If you want to work on bugs but don't yet know how to program or
maintain packages, then you may prefer this instead:

[1] If your primary focus is main, you may be tempted to say "oh, they're
    in universe, so they don't matter very much".

    Firstly, the noise causes a problem in itself; many Launchpad bug
    views don't make it particularly easy to see what component bugs
    affect, and we often have to filter things out in order to do
    release management effectively.

    Secondly, we often have to promote packages from universe or fix
    problems in universe in order to meet user/customer demand or clean
    up various bits of the archive, so allowing universe buildability to
    be a swamp causes us velocity problems.

    Thirdly, we provide universe for the benefit of our users; even if
    Canonical engineers generally have main as their primary focus, we
    all lose out if our users are having upgrade problems due to a
    popular package in universe failing to build and so being stuck on
    an old version of a library that conflicts with other newer
    packages, or something like that. [2]

[2] Longest footnote EVER.


Colin Watson                                       [cjwatson at]
Build fixes today: loqui, kanatest, nast (sync), mah-jong, ldapdns,
                   pinfo, inspircd

More information about the ubuntu-devel mailing list