Five build fixes a day

[hugo shepherd]

The trouble with rebuilds is that more (new) bugs, appear to jump in
the place of the ones you've fixed - and like the Forth Bridge in
Scotland - its a never-ending job to paint it from end to end (well
that used to be the case but now the painter's of the bridge have
deployed a new strategy which speeds up the painting of the bridge)
;-) !

Hugo Shepherd

On 12 September 2011 16:02, Colin Watson <cjwatson at ubuntu.com> 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,
>
> --
> Colin Watson                                       [cjwatson at ubuntu.com]
> Build fixes today: loqui, kanatest, nast (sync), mah-jong, ldapdns,
>                   pinfo, inspircd
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>



-- 
"When once you have tasted flight, you will forever walk the earth
with your eyes turned skyward, for there you have been and there you
will always long to return". Leonardo da Vinci


Hugo Shepherd