On Tue, 2016-04-19 at 13:48 -0600, Chris Murphy wrote: > On Tue, Apr 19, 2016 at 1:11 PM, Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > QA referred the question of whether upgrades from a release where i686 > > was 'release blocking' (<24) to releases where i686 is 'non blocking' > > (>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 > > "no". > So no matter what, all i686 images (qcow2, raw, ISOs) are non-blocking. Yes. > Any i686 package that fails to build means it's failed for all primary > 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 > up composes. 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, rather > 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 and > > 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 to use > 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. -- 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
