On Tue, 2016-04-19 at 17:22 -0600, Chris Murphy wrote: > > > It is primary. That's all. It is a primary arch. In all the actual > > meanings of that term. It is not 'in practice' secondary. It is > > primary. "In practice secondary" is a bad way to describe what you're > > trying to say and just confuses things. Please don't. :) > OK to me it seems like some kind of loophole has opened up here. Since > the critical packages build OK, composes continue. If such a package > didn't build, composes would stop. No they would not. This is the thing you're missing. The composes only break if whichever package build most recently succeeded and got pushed stable is now so broken it prevents the compose working. If 'foo-1.0-1.fc25' is in Rawhide right now and you send a build of 'foo-1.0-2.fc25' and it fails on i686, 'foo-1.0-1.fc25' doesn't magically disappear. It stays there. The consequence is just that 'foo- 1.0-2.fc25' doesn't go out. The 'loophole' you describe *does* exist, but it's not as severe as you think. > Alpha has shipped without i686, and we've heard crickets and maybe a > couple of zombie moans (if that). Do we ship beta and final without it > working? The current agreement is that we would, yes. This is what has been explicitly decided. > It's maybe not yet ridiculous, but I think everyone would > agree if Fedora 24 ships without any i686 media at all, considering > i686 a primary architecture is kinda funny. Sure, I agree. But that is how things are at present. That's how they work within the systems we've built. 'primary arch' has a definite and specific meaning that is tied to the release engineering systems that are in place, it's not just an arbitrary term. If you want it to mean something else we have to change what those systems actually *do*. If you want i686 not to be a 'primary arch' any more, the meaning of that is 'enforced' by that term's association with how the release engineering tools behave. > You know, funny like the > body out in the middle of the street, that each time someone brave > enough goes to check on the pulse just comes back and shrugs because > they don't really know so they just leave the body out there. "Hey > maybe he'll stand up next week!" > > > https://fedoraproject.org/wiki/Architectures > > When I read that, i686 sure doesn't seem like it's primary. But you're > right, it's definitely not secondary. I would kinda quibble with that page. I would especially disagree with the text "To put it simply: These are the architectures for which Fedora will delay a release if they are not functional." That is *not* the actual definition of a 'primary arch', and I think whoever added it had an imperfect understanding. I like wiki pages, but when they're wrong, they're wrong. =) The dissonance here is really because in the past there *was* a perfect overlap between 'primary arches' and 'release blocking' deliverables: the exact same set of deliverables was 'release blocking' for each primary arch. But that was never really a cast-iron guarantee. It started to fray when ARM became a primary arch (because ARM's release- blocking deliverables are significantly different from the Intel arches') and broke entirely with the decision that no i686 images would be 'release blocking', *without* a decision that i686 was no longer 'primary'. Now we *COULD* absolutely enact some kind of stronger relationship between primary and secondary arches, and state that by policy any arch with no release-blocking deliverables can't possibly be a 'primary arch' and thus i686 must be demoted. We could do lots of things! But that is *not* the current state of affairs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
