On Mon, 2016-04-18 at 21:34 -0600, Chris Murphy wrote: > > > I prefer to move it to secondary because people could be relying on it still, > > it gives us a way to move forward and not be blocked on 32 bit x86. If it does > > not work then it will not get shipped. Just dropping them on the floor does > > not give as smooth a transition, nor does it give people that want it still > > the chance to pick it up and continue to carry it forward. > > Is the context Cloud, or in general? I think going from primary for > all products to totally dropping it is a problem, even if install > media is non-blocking. I have no stake in i686 at all, and I think > Cloud and Server are less affected by totally dropping i686 than > Workstation; but I think quitting i686 cold turkey needs > reconsideration. I think it might be useful to try and be clear about terminology here. We have two established terminology pairs: 'primary' vs. 'secondary' 'blocking' vs. 'non-blocking' these are entirely distinct from each other and relate to different things, at least as they've always been used before. 'primary' and 'secondary' refer specifically to *architectures* and their status in the build system. Package builds for 'primary' arches are done together, and if build fails on any arch, that package is considered failed for all primary arches and will not be tagged into any compose. Package builds for each 'secondary' arch are done in separate Koji instances and have no impact on whether the package build is considered 'good'. This is the main practical distinction between a 'primary arch' and a 'secondary arch'. It is implicit in this that 'primary arch' vs. 'secondary arch' status is *project-wide*, it cannot be decided at the level of a SIG or flavor or whatever. 'blocking' and 'non-blocking' are terms that refer to *images* (and possibly other release-related deliverables). A 'release blocking' deliverable is one to which we apply some or all release criteria and which must be present, and meet all defined requirements, for a release to be approved. A 'non release blocking' deliverable is the opposite: the release cannot be delayed for a 'non blocking' deliverable being broken or entirely absent, they are provided on a 'best effort' basis. Whether a given deliverable is 'blocking' or not *can* be decided at the level of a flavor or WG, and I believe the current process is that the WG or SIG or whatever responsible for each deliverable can make this decision, with sign-off from FESCo. The relationship between these two pairs of statuses is as follows: secondary arch deliverables cannot be release-blocking, primary arch deliverables may be blocking or non-blocking. FESCo has already decided that no i686 image for Fedora 24 or later can be 'release blocking' by policy. There is (AIUI) no wiggle room in that decision: we cannot block releases on i686 images any more. However, i686 is still a 'primary arch' within the meaning of that term: i686 builds are done in the main Koji along with x86_64 and armhfp builds, and if a build is submitted and fails on i686, that whole build is 'failed'. > If the idea is we should block on i686 in general for upgrading, I'd > agree, even though it's a pain. 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". 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. -- 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
