On Tue, Mar 20, 2012 at 11:46 PM, Adam Williamson <awilliam(a)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.