[rawhide] ideas to improve rawhide

[Kevin Fenzi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130123/d1a29116/attachment.sig>