Archive rebuild proposal for Lucid

[Scott Kitterman]

Here are some numbers for where we stand on the ever of release for FTBFS in 
Karmic:

http://qa.ubuntuwire.org/ftbfs/

389 packages FTBFS on at least one arch.  Only 12 are in Main.

We did a rebuild test that started September 9th and took a few weeks to run:

http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-
karmic.html

1,226 packages FTBFS on at least one arch during the test (which is only an 
approximation of what we could do in the archive in many respects).  93 of 
these were in Main.

641 packages (of which 90 were in Main) had uploads after the rebuild.  Most 
should have done better, but we didn't have an easy way to track exactly.

585 packages (of which 3 were in Main) weren't uploaded again after the 
rebuild and are presumably unbuildable currently.

When I first looked at these numbers I thought they were very impressive and a 
good basis for confidence about our situation.  More than half the packages 
that FTBFS in the rebuild had post-rebuild uploads and the difference between 
the known FTBFS (389) and the known unfixed rebuild FTBFS (585) doesn't seem 
like a lot and some of these packages got removed, narrowing the gap further.  
In the context of 16,158 source packages in Karmic, that's a small percentage.

When I looked the second time, I noticed something that made me a lot more 
concerned.  The 389 number from the archive is all 7 architectures.  The 585 
from the rebuild is only i386 and amd64.  If I look at the i386/amd64 FTBFS in 
the archive it's only 55 (of which none are in Main).  So the apples to apples 
comparison isn't 389/585, it's 55/585.

When I look at it that way, I'm a lot more concerned that we have a significant 
fraction of the archive that's unbuildable on at least some architectures  and 
is unsupportable/fixable (this is particularly concerning for security 
support).  In many cases these are easy to fix, but some are equally almost 
impossible.

Particularly for Lucid, since it's an LTS release, we want everything to be 
supportable.

My proposal is that once the Lucid toolchain is in place, we do another 
archive rebuild test and then do a binary removal of any packages that fail 
(modulo not completely breaking the archive and having to reboostrap).   From 
then on, we could be confident that any package that had a binary had built at 
least once during the cycle and should build/be relatively easily buildable 
after release.

I wouldn't propose removing source, because we want these to get fixed.

Along these lines, I did ask for removal of one package that couldn't be built 
that had sat untouched since before Warty released.  We have a lot of really 
old dead stuff that no one is going to miss.

Scott K