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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel