On Thu, Apr 21, 2016 at 12:32 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Wed, 2016-04-20 at 11:43 -0500, Dennis Gilmore wrote: >> if a dracut i686 build fails the dracut build fails and nothing changes, the >> compose is not blocked. your view here is not quite the reality of the world. >> moving i686 to secondary does not change that. > > well, wait, moving i686 to secondary *does* change that, doesn't it? If > i686 is secondary, and a dracut i686 build fails, then the dracut > x86_64 and armhfp builds will still get tagged, right? Just like right > now, if dracut fails to build on aarch64 but succeeds on the primary > arches, those primary arch builds get tagged. No, because we still need i686 in x86_64 multilib because of some proprietary "stuff" (no idea, I don't use it) >> particullary in the way releng >> is looking to redefine secondary arches. > > I would like to read more about this 'redefinition'. Where can I? In Flock Rochester talks. It was discussed in Dennis's rel-eng talk, that should all be on video, and in the hallway quite widely where I discussed it with a lot of groups/individuals. Basically for example it currently makes sense to say promote aarch64 for server but not workstation (although that's starting to actually move somewhere) and cloud so how do you define primary and secondary? Well basically you remove koji from that definition and define it on the product outputs. With i686 discussing/doing this for cloud/server that is already basically happening. This is already done internally for brew (internal brew for those that don't know) where all architectures are built in the one build system. As a person that has dealt with builds across 6 secondary arches over the years the "failures" come into a few general categories: * archful builds that if they fail will fail on any architecture - this is 95% of the package set and the maintainers already deal with that * noarch builds that generally don't cause issue (and could currently get x86_64/armv7/ppc64/ppc64le builders now anyway) * core toolchain build issues (gcc/binutils/glibc and friends) - the maintainers already deal with secondary arches and end up doing multiple koji builds of their packages now * kernel - already has process that actively deals with secondary arches * a of arch specific HW - already dealt with in packages either by the maintainers or arch maintainers * software written for a specific arch - as with arch specific HW, but this may change in time (see docker stack as a good example here) again already explicitly dealt with and gets adjusted with time * packages with arch specific failures - bugs filed, arch specialists assist, already process in place, would need adjustment, the biggest one here is generally endian assumptions. These are generally a very small amount a cycle easily < 1% of the package set So in your dracut example above I don't ever remember seeing it fail on other arches and not on x86_64 too. Peter _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
