On 29/06/2013, at 7:12, Chris Murphy <li...@colorremedies.com> wrote:
> > 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. Doesn't matter much : radeon macs get hit by https://bugzilla.redhat.com/show_bug.cgi?id=975280 on all kernel 3.9. (no x, no plymouth, black screen) So fedora 19 is somewhat useless on some intel macs. Sincerely, William -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
