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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
