On Wed, 23 Jan 2013 20:02:44 +0000 "Daniel P. Berrange" berrange@redhat.com 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 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.
kevin