On Wed, May 10, 2017 at 1:39 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
For a little background, yesterday we had a very long discussion of a
bug[1] during the blocker bug meeting. The quick overview of that bug is
that Firefox failed to build on some non-x86 architectures, so the
package maintainer opted to stop building Firefox on anything but i686
and x86_64. This had the cascading effect of causing the alternative
architecture composes to fail (including ARM/XFCE).
During that meeting, I argued that the specific firefox bug didn't
violate any criteria and that we should create a new bug[2] and mark
that one as a blocker. However, I think I argued my contradicting
example a bit too well and it was misconstrued that I was suggesting
that we drop Firefox on alternative architectures and call that a
solution. My point was mostly that I wanted us blocking on a bug that
described the failed criteria, not dictating a specific solution.
I went digging through the criteria to try to find something that I
could cite to get the Firefox issue back onto the blocker list (because
on reflection *do* think it's extremely serious and I've considered
taking it to FESCo for their override). However, it seems that our
blocker criteria do not describe one institutional guideline that we've
been trying to follow: that alternative architectures should be
delivering the same content as the "primary" architectures.
What I would like to propose (wordsmithing welcome) is an addendum to
the Beta criteria under the Installer->Default Package Set requirements:
"The default package set installed from blocking media must be the same
on all architectures for that Edition, Spin or netinstall except for
packages whose sole purpose is hardware enablement for one or more
architectures."
Breaking it down, I think we should have an explicit criterion that
installing the default package set for e.g. XFCE spin on armv7 must be
the same set of packages you would get in a default install of e.g. XFCE
spin on x86_64. If there are specific examples of where there are known
(non-hardware-enablement) packages for which this is impossible, I'd
suggest adding a clause like "FESCo will maintain a list of packages
exempt from this requirement".
So I'd like for us to consider including this requirement for F26 Beta
(though I realize time is a little short on that score). If Fedora QA
feels that it's too late for us to add this criterion, I'll take the
specific matter of the Firefox builds to FESCo. I do think we should set
a precedent here and document it for the future.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1443938
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1448923
I don't really understand this, and I haven't read the meeting log, so I apologize if my questions are dumb.
Why would we dictate that Editions/Spins can't use different software on different architectures? It might make perfect sense to use browser X on x86_64 because it's very good, but use browser Y on i386 because of memory limitations of i386 arch (browser Y needing much less memory than browser X). Similarly, if shell A no longer supports i386, why would be ban it from being preinstalled on x86_64? i386 would have shell B instead. Those are random examples, but it seems to me that they can be completely valid. If there's such requirement that Editions/Spins can't install different software on different arches, I think that should be established by FESCo, not us.
Why would we dictate that Editions/Spins can't use different software on different architectures? It might make perfect sense to use browser X on x86_64 because it's very good, but use browser Y on i386 because of memory limitations of i386 arch (browser Y needing much less memory than browser X). Similarly, if shell A no longer supports i386, why would be ban it from being preinstalled on x86_64? i386 would have shell B instead. Those are random examples, but it seems to me that they can be completely valid. If there's such requirement that Editions/Spins can't install different software on different arches, I think that should be established by FESCo, not us.
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. If it hadn't excluded arm, it would not be a blocker, and alternate arches would need to find a way (fix the bug or use a different browser). If you still think this should not happen, you could ask FESCo to present some rules saying when Fedora packagers can exclude other arches from the build and when they can't. We could then enforce that (instead of prohibiting different package sets).
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
