Five build fixes a day
micahg at ubuntu.com
Mon Sep 12 16:28:34 UTC 2011
On 09/12/2011 10:02 AM, Colin Watson wrote:
> 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 , 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 (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:
>  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. 
>  Longest footnote EVER.
I can try to do this as an average of 25 per week.
More information about the ubuntu-devel