RFC: Primary architecture promotion requirements

[Peter Robinson]

On Tue, Mar 20, 2012 at 11:46 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote:
>
>> 2) Updates.  Submitting updates requires the entire build to be complete
>> which means you have to wait for the slowest thing to finish.  Having to
>> wait for 12 hours effectively means you can't even test your update until
>> the next day, and then after you test it you can submit it.  Again, this
>> is mostly compounded for large packages, but it does impact workflow.
>
> From a QA perspective, there's a fairly important instance of this case.
> We sometimes wind up working on very compressed timescales in validation
> sprints. We don't get very long to do validation.
>
> So it's not unusual for me to be bugging, say, the kernel team to give
> us a new kernel build that fixes a blocker bug, so we can do a new
> release candidate, so we can test the release candidate in twelve hours,
> so we can make the go/no-go meeting deadline the next morning.
>
> If builds get significantly slower, that could have a concrete impact on
> the release validation process: it's plausible that we'd either need to
> extend the validation period somewhat - earlier freezes - or we would
> have to eat a somewhat higher likelihood of release slippages.

Thanks Adam, this is the first real use case where speed of builds is
important for something other than keeping the developer happy.

Peter