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