On Wed, Jan 23, 2013 at 02:23:01PM -0700, Kevin Fenzi wrote: > On Wed, 23 Jan 2013 20:02:44 +0000 > "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > > > If the deps provided by a new build have changed, then verify that > > the change deps don't cause breakage. If they do, then do not allow > > the new build into the rawhide target. Queue the build in some kind > > of build specific 'pending' target. Let all the broken deps be fixed > > in that pending target, and then atomically merge that target back > > into rawhide target. Basically at no time ever, should you allow > > broken deps to make it into rawhide. As long as our build process > > allows for broken deps, then rawhide is going to be a trainwreck > > of some kind or another. Requiring people to pre-announce deps > > breakage to let people promptly rebuild has unequivocably failed to > > solve the broken deps problems. We need to have a way to deal with > > this in our build tool chain permanently without humans as the > > failure point. > > I agree. We could possibly use something like: > > build finishes for f19, lands in a f19-pending > autoqa runs on the package, if it passes, tag it in to f19 > if it doesn't, mail maintainer/etc about it. If it doesn't pass I think it is critical to move it into a private tag eg f19-<RPMNAME>-pending, so that you can do the downstream rebuilds against it in isolation from any other builds in f19-pending or rawhide. > If there's some compelling reason it has to land, the maintainer can > override and tag into f19 directly. (and then explain themselves :) > > But we would need the autoqa part to exist and be ready for this. I dunno what the scope of autoqa is, but even a simple dependancy check would be sufficient - no need to wait for a full automated qa system to be built. IMHO the key is that if we ever want rawhide to be generall useful and consumable, we need to fix the "broken deps" problem permanently. As long as we have the current mess of broken deps in rawhide, I'll never go anywhere near rawhide for my day to day work. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
