Release criteria proposal: conflicts / dependencies

[Adam Williamson]

On Fri, 2010-10-01 at 16:16 -0400, Paul W. Frields wrote:
> On Fri, Oct 01, 2010 at 01:10:28PM -0700, Adam Williamson wrote:
> > On Fri, 2010-10-01 at 15:58 -0400, Paul W. Frields wrote:
> > 
> > > > I like to see that always be a requirement for the stable, stable+updates
> > > > and rawhide (assuming the rawhide-pending tag becomes a reality).
> > > 
> > > I would like to see this eventually too.  However, we don't have a
> > > capability to stop it from happening, other than our current method of
> > > relying on people to do the right thing.  That could effectively mean
> > > that anyone could inadvertently hold up shipping a release at "the
> > > edge of space" through a bad push.
> > 
> > This isn't actually the case, as no-one can push directly to any of
> > those places, certainly just prior to release. (Well, except security
> > updates.) Everything goes to updates-testing first; we can catch broken
> > deps there and refuse to push them into stable.
> 
> I was going to argue that we've had this problem occur in the case of
> security updates with e.g. web browser stack, but on the other hand
> that would be in the critical path anyway.
> 
> I may be out of touch here, for which I apologize in advance.  What
> mechanism currently prevents broken deps in updates-testing from being
> pushed into stable?

Just the usual testing. But just prior to release the freeze is in
place, and packages are only taken from -testing to stable after manual
review by qa and rel-eng, and only to fix blocker or nth bugs; this is a
pretty intensive and managed process and we'd be very unlikely to push a
package from -testing to stable at that point which had broken deps. I
don't think it's ever happened.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net