On 05/11/2017 02:53 AM, Kamil Paral wrote: > > > On Wed, May 10, 2017 at 10:24 PM, Adam Williamson <adamw...@fedoraproject.org > <mailto:adamw...@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. 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. That way the standard behavior is the same for all of them. This also puts pressure on the maintainer to fix it for the arch(es) that are broken if they or the Spin owners want it available. Maybe it doesn't need to be as wide-reaching as my original proposal, but I think we need this for at least the default application sets.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
