RFC: Primary architecture promotion requirements
pbrobinson at gmail.com
Wed Mar 21 13:26:52 UTC 2012
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.
More information about the devel