On Tue, 2016-04-19 at 13:48 -0600, Chris Murphy wrote:
On Tue, Apr 19, 2016 at 1:11 PM, Adam Williamson
> QA referred the question of whether upgrades from a release where i686
> was 'release blocking' (<24) to releases where i686 is 'non
> (>23) should be considered 'release blocking' to FESCo. i.e. if there
> are violations of the release criteria in this upgrade path, should we
> treat that as blocking the Beta or Final releases. FESCo's decision was
So no matter what, all i686 images (qcow2, raw, ISOs) are
Any i686 package that fails to build means it's failed for all
archs, because i686 is a primary arch. And a failed build means it
won't be tagged for compose so depending on the package it could hold
True, though I hadn't actually mentioned that scenario. But indeed. Say
we needed a fix to dracut, pronto, to make the x86_64 cloud base image
boot, but the build with the fix failed on i686: that would have to be
dealt with somehow. Good point.
But the current i686 problems aren't package build failures,
it's a particular critical path package (or two) that are broadly or
entirely non-functional when executed. So what's it called when a
critical path package fails to function on a primary arch? And what's
done about it?
A bug? :)
Basically AFAIK no particular 'special' status attaches to this
situation. It's just...a bug.
From my limited perspective, such non-functional failure held up
release when it violated a release criterion in effect because that
non-functionality became coupled with image blocking, i.e. if kernel
doesn't function, then image doesn't function/is DOA, DOA images are a
release criteria violation, therefore block. Correct? Or is there some
terminology nuance here that I'm still missing in the sequence?
No, even in this case there is no release blocking impact, because
nothing release blocking is broken by the bug. The i686 images are not
release blocking, end of story. Even if they are completely DOA, that
does not block release.
This is exactly the situation that occurred with F24 Alpha, as it
happens. All 32-bit F24 Alpha images fail to boot in at least a lot of
cases, maybe all cases. We went ahead and shipped Alpha anyway. The
only concession was to try and downplay the existence of the 32-bit
images in the release notes and download pages.
> I really think it would help if we use these terms carefully
> precisely, and if we're going to re-define them in any way, make that
> clear and explicit.
It's best to assume I don't understand the terms well enough
them precisely, rather than assume I'm trying to redefine them.
I was not actually thinking of you there (I just picked your post to
reply to since it was at the top of the pile), more the vagueness in
the thread in general.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net