On Thu, 2017-05-11 at 08:01 -0400, Stephen Gallagher wrote: > On 05/11/2017 02:53 AM, Kamil Paral wrote: > > > > > > On Wed, May 10, 2017 at 10:24 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx > > <mailto:adamwill@xxxxxxxxxxxxxxxxx>> wrote: > > > > On Wed, 2017-05-10 at 16:52 +0200, Kamil Paral wrote: > > > For this particular Firefox example, what is the core problem that you're > > > trying to fix here? Is it the fact that Firefox excluded many arches from > > > builds? From my QA POV, since it excluded arm, it's a blocker, since arm is > > > primary. > > > > There is not, in fact, any blocker criterion which simply makes it a > > blocker issue to disable a package build on a primary arch. There are, > > I think, several 'legitimate' cases of this, in fact. > > > > > > I didn't specify my full thinking process. I wanted to write it like this: > > firefox no longer available for arm -> arm is primary arch -> release criteria > > apply for arm -> release criteria say that default browser must work -> blocker > > (until either firefox is available and working again, or until that particular > > arm edition replaces firefox with a different default browser) > > > It's that last part that bugs me. While I know it's the way the rules work today > (and I argued on Monday to follow the letter of the rules), I think that we > should really have another rule that prevents this moving of goalposts. I don't really see why. To me, it's getting beyond the appropriate business of the release criteria. It's generally the case that deciding the appropriate *resolution* to blocker bugs is ultimately up to the relevant maintainers. In this case, it'd be the Xfce SIG, at least immediately: if they don't think that switching browsers is acceptable, well, there's no problem. If they *do* think it's fine for the Xfce spin to use a different default browser (as I believe it has in the past), I don't immediately see why the release criteria should overrule them. > At the very least, I want a rule that would accomplish the following: If XFCE > Spin on ARM cannot use Firefox, then XFCE Spin on x86_64 (and others) cannot > ship Firefox by default. My biggest cause for hesitation here is this the saying "hard cases make bad law". Have you tried to think through the consequences of this in all other possible cases, or are you just slapping a band-aid on a problem that doesn't even *exist* yet? We only brought up the possibility of switching default browsers to *illustrate* why the blocker isn't technically just "Firefox doesn't build on ARM"; no-one actually *suggested* switching browsers would be a good idea, and I haven't heard anyone from the Xfce SIG say they want to do it yet. I'm really reluctant to make what seems like quite a complicated rule on the basis of a single case of something that actually hasn't happened yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
