Five build fixes a day

[Micah Gersten]

On 09/12/2011 10:02 AM, Colin Watson wrote:
> 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,
>
I can try to do this as an average of 25 per week.
Thanks,
Micah