On Tue, Mar 20, 2012 at 11:46 PM, Adam Williamson <awill...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
