On Tue, Nov 15, 2016 at 4:45 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: On Mon, Nov 14, 2016 at 4:52 PM, Andreas Tunek <andreas.tunek@xxxxxxxxx> wrote: >> How do you fix it if you can't install the release? Do you make a new >> release with all the testing again (to make sure you do not have other >> regression bugs)? > > Anaconda has updates.img, which might be usable post-release. Barring > that, there are the update respins that other community members do. > Pretending those don't exist seems silly. The silly pretense I see is the notion there's an idea how to do this, let alone a policy or procedure in place. What's in place right now is a release blocking criterion that was not being met, so the release was blocked. The criterion is not a secret or new, the process is not secret or new, yet somehow there's an 'oh shit we're blocking the entire release just for Macs?!' reaction, as if there's something fundamentally different compared to any other time we've had a last minute blocker bug that only affects a minority. Because of the monumental testing that happens, there's a really good chance a last minute blocker ends up affecting only a minority. That is how the process works. All you have to do is read the list of release criteria and realize that it's a very consensual process where an affected minority can block the entire release. Unsurprising. Not news. I also think it's a silly pretense that we'd be having this conversation if the exact same problem happened with Windows dual boot. There'd be no serious proposal to drop Windows dual boot as a release blocking criterion. To test that hypothesis, I propose a new policy that requires 100% of test cases which are attached to a release blocking criterion, shall have been performed by some milestone, perhaps sometime between beta GA and final freeze. If the test hasn't been done, the applicable criterion is put in a one cycle abeyance, i.e. bugs found to violate the suspended criterion will not be accepted as blockers for final for the release. Another possibility is that maybe the Mac and Windows criterion should be beta milestones. QA always says nothing prevents earlier testing, but in reality a bunch of final tests don't happen until well after final freeze, it's just the way it goes in Fedoraland. > >>> Lastly, support is a very loaded word, particularly in the context of >>> a community driven project. We actually do not have an x86 equivalent >>> of the ARM supported-boards list, so it's completely random as to what >>> laptops and desktops are tested and prioritized. That might be >>> something to focus on going forward. >> >> It has been in the release critera that you should be able to install >> on macs and it has worked for a very long time. If you are going to >> remove that support you should really let people know in advance (not >> a week before release). > > Again, nobody is saying "remove support". We're saying "fix it later". The blocker hammer is what's been meant by support for a long time now. There is no mechanism for supporting a thing and fixing it later. When it's not important to block on, it doesn't get fixed. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
