Quantal archive rebuild proposal
micahg at ubuntu.com
Fri Apr 27 22:46:50 UTC 2012
On 04/27/2012 05:20 PM, Scott Kitterman wrote:
> On Friday, April 27, 2012 05:13:21 PM Micah Gersten wrote:
>> Now that we have the faster i386/amd64 buildds, I'd like to suggest at
>> least one extra rebuild earlier in the cycle at least for i386/amd64 so
>> there's time to get these changes upstream.
>> Around alpha 1 ~ June 7 (archive raw, lots of failures, should catch
>> most of the Ubuntu change related gcc-4.7 issues though)
>> After Feature freeze ~ Aug 23 (archive should be fairly stable for most
>> dependency trees, check to see what new failures were introduced through
>> new upstream versions)
>> During beta 2 freeze ~ Sep 25 (shake out the last round of failures)
> My initial reaction is that we're learning plenty from the existing rebuilds.
> There's no real need to add to the pile of work we don't have time to do.
> The rebuilds do have a negative effect on distro development because, even
> though they have a low priority in Soyuz, when all the builders are full due
> to rebuild packages being built nothing can start until one of the rebuild
> packages finishes. Since they build in alphabetical order, about the time you
> hit gcc*, this can really slow things up.
> I would not add more rebuilds unless it's really clear there will be benefit.
> Until after DIF much of what turns up in a rebuild is inevitably archive skew
> that it's not hard to find other ways.
> Scott K
Now that we can use -proposed during development, the only arch skew
should be from autosyncs. The current failures do tell us a lot, but
quite a few will probably be fixed with the autosyncs as well.
Remaining failures from the last rebuild in precise:
Main archive Ports archive
i386 amd64 armhf
arch (F) Package failed to build 116 85 148
arch (M) Package is waiting on another package 9 7 105
So, most of the armhf failures are related to gnat-4.6 not being
available. That leaves a little more than 100 failures some of which
will be resolved with autosyncs (also most are probably not easy
fixes). A new rebuild would give people a chance to pick off easy fixes
and also let us know where we stand WRT new failures early on.
So, maybe we should wait until after DIF, then there would be very
little risk of archive skew during the rebuild.
Another thing to consider, is with Debian freezing for Wheezy at some
point, the likelihood of fixes from new upstream versions getting in
through Debian decreases as we get further into the cycle.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ubuntu-devel