On Wed, 2007-05-30 at 13:24 -0400, Jesse Keating wrote: > On Wednesday 30 May 2007 13:17:17 David Woodhouse wrote: > > And it wouldn't need to be. I think I still haven't quite communicated > > what I mean. > > > > 1. A build is submitted. > > 2. It fails on some architecture. > > 3. All other architectures run to completion. The packages can be > > fetched from koji immediately, and perhaps even used for building > > new dependent packages¹. > > 4. The build is not complete (or 'committed') until all architectures > > for which it was _attempting_ to build are spoken for -- either with > > a successful build, _or_ a 'retrospective ExcludeArch' bug being > > filed (and put in the specfile). > > So why can't this all be done automagically? Upstream Fedora koji gets a > build request. It is built, and it succeeds. This triggers secondary arch > koji instances to build the same cvs url. If the build fails, auto file a > bug with appropriate blockers/trackers. Upstream keeps going unhindered, > arch team looks into it with package maintainer. I'm concerned that this will be difficult to code correctly, specifically the "automagic bug filing". The first failure is easy, but what if I thought I fixed it, but hadn't. It files a new bug. Rinse, repeat, bloat bugzilla and/or spend time chasing down dupes. I could be wrong about that though. The very specific logic path is this: 1. A build is submitted. 2. Primary architectures run. If any primary architecture fails, it stops. 3. When all primary architectures pass, then the build is sent to all secondary architectures. 4. Each secondary architecture runs to completion. Failures by any secondary architecture do not affect other secondary architectures. 5. Secondary architectures which failed make a lot of noise. (This is where automagic bug filing occurs, emailing architecture teams, etc). ~spot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
