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 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
