RFC: Primary architecture promotion requirements

Josh Boyer jwboyer at gmail.com
Tue Mar 20 19:05:24 UTC 2012

On Tue, Mar 20, 2012 at 2:59 PM, Brendan Conoboy <blc at redhat.com> wrote:
> On 03/20/2012 11:16 AM, Jesse Keating wrote:
>> You are materially impacted. AutoQA won't run until the entire build is
>> complete. Updates cannot be prepared until the entire build is complete.
>> Buildroots won't be updated with the build results until the entire
>> build is complete. You won't know if your build /fails/ on the arch
>> until it's done, etc...
>> Having one arch significantly slower than the others absolutely creates
>> material impact upon developers.
> I haven't run this by anybody yet, so if it's nonsense just say so, but...
> Would it be reasonable to, even amongst primary architectures, allow these
> steps to go forward even if one arch fails while another succeeds?  Let's
> say we have arch-groups in primary- i686 and x86_64 are in a group, armv7hl
> and armv5tel are in a group.  The results of one group do not inhibit the
> progress of another.  Feasible with a bit of retooling, or a nightmare
> waiting to happen?  The discussion so far has focused almost exclusively on
> build time.  We hear you.  Let's talk about what to do about it.  And what
> concerns there are besides build time.

You mean aside from what you already have as a secondary arch, which allows
this explicitly?

What would you look to gain by having a half and half arch?  All of the PR
but none of the requirements for consistency and quality?  I can sympathize
with trying to be creative on solving a concern, but this probably is not
how you want to go about it.


More information about the devel mailing list