On Thu, 2016-08-04 at 16:07 +0100, Peter Robinson wrote: > Hi All, > > We are planning to change the way Alternate Architectures (non x86_64) > are handled > in terms of "primary" vs "secondary". The definition of what is > primary or secondary > is already handled more in terms of the build artifact outputs (images, LiveCDs, > installers, containers etc) for i686 deliverables. As part of this redefinition > this means that the location in "koji instances" of the rpm builds is removed as > a part of the definition requirement of what constitutes > primary/secondary and the > architectures are named "Alternate Architectures" (and Experimental > architectures > for the likes of MIPs/RISC-V) as opposed to primary/secondary. As a > result of this > change it is planned to merge the old "secondary" koji instances into a single > koji instance along with all the current "Primary" architectures. > > All the details of the proposal along with FAQ have been put on a wiki > page here[1] > so please go and read it and ask any questions that aren't answered in > the FAQ here. I do have serious concerns about the impact of this in terms of build failures. Reading the reply to " Q: Why do I have to worry about s390x/powerpc/aarch64 when I didn't before?", it implies there will be no change to koji in terms of build failures: i.e. a failure on *any* arch will cause the entire build to be failed. The answer...honestly does not convince me. I think the result will be a combination both of an increase in failed builds and the issues caused by them, and an increase in the number of packages which simply disable building on an arch entirely due to a lack of will to deal with build issues (and/or slow build time) on that arch. With secondary koji instances, neither of these are major issues, and secondary arch teams are able to work on build fixes for those arches without the maintainers being bothered by them. Has any consideration been given to the possibility of increasing Koji's flexibility here, by allowing for arches to be designated as non-fatal, so a package build failure on that arch would not cause the task to be considered a failure? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
