On Wednesday 30 May 2007 12:42:35 David Woodhouse wrote: > Of course, and we currently strike a balance which is working very well. > It involves package maintainers at least _looking_ at failures, and > filing a bug if they end up satisfied that it's an arch-specific issue > and using ExcludeArch. Then the people who care about the architecture > in question can watch the FE-ExcludeArch-$ARCH bug and handle anything > which comes up. > > It's working _extremely_ well at the moment -- there really seems to be > no reason to change it. In the relatively rare case where a failure > really is an arch-specific issue and not just a package bug, it's easy > enough for the package maintainer to file the bug and exclude the > offending architecture. > > Build failures should _always_ be investigated, at at _least_ a cursory > level, before letting the affected packages get into the repository. > To require anything less than that is completely batshit insane. It's working well because there is exactly one "secondary"ish arch, and that's ppc. Although one could argue that x86_64 is one, but not really. And ppc has you, plus a few others that are extremely vigilant about fixing things. What we're talking about with this new policy is opening it up for say s390 to be a secondary arch. Arm. ia64. Alpha. That's just 4 off the top of my head. Now you're going to make every build wait for 4 other downstream build systems to build, if they can, when they can, before a package build can be 'complete' for anything, including the primary arches. You're expecting a maintainer to care that his/her build of frobitz failed on arm, of which (s)he has exactly 0 exposure to, and be able to either fix it, get in touch with the arch maintainer who may be offline at the time, or waste more time/effort by throwing in another ExcludeArch. Or, we let the secondary arches pick up actually completed builds from the primary arches, build them when they can, if they fail alert anybody necessary and maybe even auto file a bug. It will be up to that arch to fix things, but it will not slow down the primary arches from continuing on and marching forward. We have extremely short release cycles and can't be stymied by an arch that just isn't keeping up. -- Jesse Keating Release Engineer: Fedora
Attachment:
pgpqW0houtHnU.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
