On Jun 28, 2013, at 10:39 AM, Matthew Garrett <mj...@srcf.ucam.org> wrote:
> On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote: > >> - Say we ground all the wheels to a halt and slipped for this bug. >> Where to do we draw the line? If someone comes up with a bug at >> 9:50am on release morning, do we cancel everything? There has to be a >> point where we say "sorry, it's too late" and this has been it since >> it makes sense from a logistic standpoint. > > If at 9:50am on release morning we discovered that the installer would > format all connected drives if the month had two digits, I'd like to > think we'd do something about it. It's inevitably going to be a > judgement call based on the perceived harm in releasing as is against > the harm caused by slipping, just as it is at any other point in the > release process. Current policy effectively says "There is no issue > sufficient to delay release after we've said an image is good", and I > don't believe that that's true. One possible solution is either more padding (time) between any RC release and go/no-go; or if certain listed packages, like anaconda, pykickstart, blivet, etc. are touched in even a seemingly trivial way, then the full QA test matrix has to be retested. Maybe that's already implicitly the case, but I don't know if it's a rule. But what definitely isn't the case is, Macs are still not officially supported by QA for blocker status for Mac specific major bugs. If a Mac only bug comes up, block status is rejected on the basis that too few people will experience the bug. So before I'd suggest holding up Fedora 19, I think Macs need to have a promoted hardware status. Something not totally dissimilar happened for Fedora 18 that was also a problem for Macs. That's bug 893839 "Mac EFI from DVD and LiveCD ISO burned to actual DVD media results in grub prompt, no boot". I didn't find that until final, definitely too late. But the final release series of RC's happen very quickly, and any allowed change is by definition significant (i.e. necessary) or it simply wouldn't happen, but that also makes the change higher risk than other changes. So I think more time padding is needed between an RC and go/nogo. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
