Five build fixes a day
Colin Watson
cjwatson at ubuntu.com
Mon Sep 12 15:02:24 UTC 2011
We have 661 build failure bugs open right now:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=ftbfs
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:
http://wiki.debian.org/qa.debian.org/FTBFS
http://wiki.debian.org/ToolChain/DSOLinking
https://wiki.ubuntu.com/ARM/FTBFS
Please remember to forward patches to Debian and usertag them
appropriately (https://wiki.ubuntu.com/Debian/Usertagging, and note the
usertags in http://wiki.debian.org/ToolChain/DSOLinking 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:
https://wiki.ubuntu.com/5-A-Day
[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.
Cheers,
--
Colin Watson [cjwatson at ubuntu.com]
Build fixes today: loqui, kanatest, nast (sync), mah-jong, ldapdns,
pinfo, inspircd
More information about the ubuntu-devel
mailing list