On Tue, Mar 20, 2012 at 2:59 PM, Brendan Conoboy <blc(a)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.
josh