Review of Fedora 18 Release Criteria

[Tim Flink]

On Wed, 10 Oct 2012 16:43:36 -0400
David Cantrell <dcantrell at redhat.com> wrote:

snip

> > > I didn't read this paragraph.  This is a lot of text, but I've
> > > skimmed it. What I think we should consider is whether Fedora
> > > should have a separate entity or group that accepts blockers.
> > > Right now, that responsibility is largely falling on your team.
> > 
> > This isn't really the intent. The blocker meeting SOP -
> > https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting - reads:
> > 
> > "Blocker Bug Meetings are not owned by any one team in Fedora. They
> > are a collaborative effort between Release Engineering, Quality
> > Assurance, Development, and Project Management."
> > 
> > and the intent is that, ideally, some or all of those groups should
> > be represented at blocker review meetings. Lately, it seems that
> > this hasn't been happening as much as it used to. We used to have
> > fairly solid attendance from releng, FPL / FPM, and interested
> > development parties. Recently it seems like these groups just
> > aren't terribly interested in showing up and the meetings tend to
> > be all or mostly QA people. And we go ahead and do the evaluations,
> > because hell, someone has to. But as the procedure clearly states,
> > it's not a QA-owned process, it's meant to be collaborative, and
> > the onus is really on other interested parties to _show up and take
> > part_. We do usually ping #anaconda when blocker review starts up
> > and ask if anyone wants to take part; often no-one does. I think
> > it's seen as taking away precious development time. It would be
> > really nice if we starting getting more developers and Robyn and
> > Jaroslav showing up for more blocker reviews. Admittedly, the
> > meetings do get very long sometimes, but we've found it pretty hard
> > to resolve that (reviewing 30 blockers is going to take a while,
> > however you slice it). I do think it helps to have multiple
> > perspectives, and that QA folks often tend to be more 'liberal'
> > about accepting blockers than other groups; it would definitely be
> > useful to have other groups present to act as a check on this.
> > 
> > It might be an idea to start CCing the blocker meeting
> > announcements out a bit more widely, to help with this. Or heck, we
> > could also have some non-QA person run the meetings for a while,
> > give it to FPL or FPM or someone. That would liven things up.
> 
> The SOP can say whatever it wants, but what actually happens in
> practice matters.  People don't go to the meetings because they take
> too long.  I'm going to make a comparison to RHEL process again, but
> I think it's useful here.  Meetings have a hard time limit.  There is
> only so much work a person can do in a day and it's ridiculous to
> keep going through bug status over and over and over just because
> it's there.  When RHEL meetings get in to "bugzilla bingo", they
> cover what can be covered in the allotted time.  What isn't covered
> isn't forgotten, just brought up at the next meeting.

Then we should change what's going on in practice. I'm generally
all for changes in the blocker review process if they make sense. If
there are reasonable things we can do to increase developer
participation, let's make those changes.

As Adam mentioned, we started imposing a time limit on the blocker
review meetings last week. I think that everyone's eyes start to glaze
over when the blocker meetings go on too long - I know mine do.

It seems that the 3 hour time limit has been going over well so far and
I think that we're going to continue doing that for now. I'm not sure
that it'll work so well if we have go/no-go the next day but I'm also
hoping that we won't have lists of 30+ proposed blockers to review that
late in the release cycle.

> And from my own point of view, I've never seen your invites in
> #anaconda simply because I do not look at IRC unless addressed by my
> nick.  I can't. I don't have time to sit and watch the text scroll.
> The length of this reply that you sent....I get hundreds of those per
> day that I'm expected to read and respond to.  Plus all the meetings
> I'm scheduled for on a daily basis.  This is not me whining, just
> trying to explain how I make the most effective use of the resources
> I have.  Direct invites to these meetings would help me work them in
> to my schedule and perhaps even attend.

When you say direct invites, are you talking about emails a day or so
ahead of time or IRC pings when the bugs come up?

Since I've been running the blocker review meetings as of late, I'm
fine with generating emails the day before and/or pinging people when
their bugs come up. The only problem is who to contact and when - using
anaconda as an example, do I send invites to anaconda-maint-list@ the
day before? How do I know who to ping over IRC when there isn't a
single assigned person to the bug? Are email invites more useful the day
before or 2 hours before or both?

I'm also going to start sorting the bug list before the meeting starts
so that we cover all of a component's bugs at the same time instead of
having them all spread out. Admittedly, that's something I should have
started doing a while ago but I can't change that - I can change how
the list is generated going forward, though.

I have some other ideas on how to improve the review process in the
long term but those ideas would take time to implement and probably
belong in another thread.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20121010/f4727d16/attachment.sig>