On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote:
2) Updates. Submitting updates requires the entire build to be
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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora