On Wed, May 10, 2017 at 1:39 AM, Stephen Gallagher <sgall...@redhat.com> 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. 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@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
