On Tue, Nov 15, 2016 at 12:19 PM, Chris Murphy <li...@colorremedies.com> wrote: > On Tue, Nov 15, 2016 at 4:45 AM, Josh Boyer <jwbo...@fedoraproject.org> wrote: > On Mon, Nov 14, 2016 at 4:52 PM, Andreas Tunek <andreas.tu...@gmail.com> > 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
I'm not surprised. I simply disagree with the decision. > if there's something fundamentally different compared to any other > time we've had a last minute blocker bug that only affects a minority. There is. Because we've genuinely waffled about impacted majority a number of times and released anyway. > 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. It's not pretense. There are, numerically, far more Windows laptops than there are Macs. The gap is closing, but it's still the case. > 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. I like this proposal. It seems to make forward progress on the things I'm actually concerned about, which is lack of resources to test all the criteria. By moving it up, we catch the gap earlier. > 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. That seems like a more specific tweak on your proposal above. >>>> 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. Untrue in the general sense. We have updates that fix things later all the time. Otherwise we'd never ship the literal gigabytes of updates we do during a release. > When it's not important to block on, it doesn't get fixed. Also untrue in the general sense. josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
