>> 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 You can't guarantee memory on any device, you should have a consistent experience in terms of applications not perceived possible issues such as memory. EG you could easily have a Power64 or aarch64 device that's faster than x86)64 with more memory. > 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 Well it causes most of the world to fail to compose on numerous architectures. EG Workstation on both ARMv7 and aarch64 is very usable and accelerated on a number of devices but now completely fails to compose, Firefox is the default browser there. > 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 > _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
