On 05/09/2017 08:17 PM, Adam Williamson wrote: > On Tue, 2017-05-09 at 19:39 -0400, Stephen Gallagher wrote: >> 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. > Nitpick: ARM *is* a primary architecture. x86_64 and armhfp are the > current Fedora primary architectures. All others are 'alternat(iv)e > architectures' (the words 'alternate' and 'alternative' seem to be used > as if they were interchangeable, in the various pages discussing this). > > Ref: https://fedoraproject.org/wiki/Architectures Apologies, that was a misstatement. > >> 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. > Well, we weren't talking about only changing the default on ARM, in the > meeting. The implication was that we'd change the default for x86_64 as > well. Since about three weeks ago we don't technically *have* to, I > think, because we tweaked comps to allow specifying packages by arch, > but we've not actually used this at all yet. > > The wrinkle in this situation is that Xfce is *only* a release-blocking > environment *for ARM*. It is not a release blocking environment for > x86_64. So I don't think the proposed criterion would actually *mean* > much in this case. If someone actually decided to push for changing the > Xfce default browser as a resolution to the bug (rather than fixing > Firefox), telling them they have to change it for x86_64 as well as ARM > probably wouldn't dissuade them. They'd just say "Fine, we'll do that." Sure, but that puts pressure on the maintainers of that spin to make a decision. If they *really* want to keep Firefox on their x86_64 platform, they'll push to get it fixed. On the other hand, if they don't actually care, then at minimum we will maintain a consistent experience across architectures. I think it's valuable to have that encoded as a blocking requirement.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
