Re: New Blocker Criterion Proposal: Same default packages for all arches
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(a)fedoraproject.org
> <mailto:adamwill@fedoraproject.org>> 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