On Wed, 2007-05-30 at 12:55 -0400, Jesse Keating wrote: > 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. How vigilant we are really isn't relevant. We only bother to get involved once the ExcludeArch bug is failed. It's precisely that requirement to file a bug which makes the system works as well as it does -- which is why I'm so opposed to effectively removing that requirement (since having to have a bug for all use of ExcludeArch: is fairly pointless if architectures can end up excluded _without_ an explicit ExcludeArch). > 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. As I proposed it, building of dependent stuff like bluez-libs followed by bluez-utils would be _faster_ than it is today. Asynchronous, but just not 'committed' and pushed to the public repo until all architectures are either finished or have an ExcludeArch bug filed. You could still get the packages from koji directly, even before they're committed. > 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. It really isn't that much time and effort to file a bug and add one line or one word to the specfile -- all build failures need to be investigated anyway. And if we allow retrospective ExcludeArch bugs, the maintainer doesn't even need to wait for the package to rebuild on the architectures on which it succeeded. > 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. There's zero chance of being 'stymied by an arch that just isn't keeping up'. You're imagining problems which don't exist. If an arch isn't 'keeping up' then it can easily be excluded. All that's required is a bug in bugzilla. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
