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 [[email protected]] Build fixes today: loqui, kanatest, nast (sync), mah-jong, ldapdns, pinfo, inspircd -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
