Release criteria proposal: conflicts / dependencies

[James Laska]

Hey Adam,

Thanks for taking this meeting topic to the list.  Comments below.

On Fri, 2010-10-01 at 13:28 -0700, Adam Williamson wrote:
> 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.

I'm not in favor of this criteria addition at this time.  I'd love to
see this happen, but I don't think it's realistic at this stage in the
release or in this forum (F-14).  Can we have more input from devel +
rel-eng who initially proposed the change?

Extending the criteria beyond packages included in the media at this
stage (F-14-Final milestone coming soon) seems like too much, too late.
I'm concerned we haven't had sufficient time to communicate these
changes to packagers/maintainers, and won't be able to rapidly respond
to issues that surface.

Some concerns ...

     1. Enforcement - As Paul points out, there is no way to prevent
        *any* package with broken dependencies/conflicts from entering
        the repos.  Adam correctly points out we have a re-energized
        'proventesters' team that will likely catch errors.  However,
        detecting the failures often depends on what packages you have
        installed on your system while testing.  Unless we require all
        proventesters to have 'Everything' installed, we cannot identify
        and prevent all failures.
     2. Familiar debate, new setting - Everyone is aware that repo
        consistency (repoclosure + conflicts) is a problem in Fedora,
        and we have tooling in development (not production) to address
        the issue.  While I agree that we should 'never' have repository
        problems, this isn't a problem specific to F-14 and I don't
        think F-14 is the right place to enable this change.  Due to the
        lack of tooling support noted above, we unable to assert that
        there will be no repo consistency issues for the life of F-14 +
        F-14-updates.  But we can continue to assert that the media
        contain consistent repositories.  Let's continue tracking repo
        consistency as a separate topic, not specific to a particular
        release.
     3. Compose - In the past, we've had issues we wanted to be aware
        of, and have resolved for the release, but they weren't
        considered true 'blockers' as they didn't block composing the
        final ISO images.  There were several issues, but the most
        notable is ensuring a stable preupgrade exists in the previous
        release.  With the proposed criteria addition, we are blocking
        ISO composition for packages that aren't on the ISO's (not
        previously, we would only block for packages on the ISO's).
        This seems like an artificial restriction.
     4. Provenpackagers - since any maintainer can update/add packages
        to Fedora, but not all maintainers are skilled/experienced
        enough to diagnose and resolve complicated dependency issues,
        have dedicated provenpackagers been identified to resolve issues
        as they surface?  Are they aware they may be needed at odd hours
        in the day to rapidly resolve issues?

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20101004/7aed9ce1/attachment.bin