Review and notification of blocker bugs

[James Laska]

On Thu, 2011-07-28 at 14:52 -0700, Adam Williamson wrote:
> I'm currently surveying the QA release calendar:
> 
> http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html
> 
> to check we have SOPs for all tasks on it. As part of that, a couple of
> tasks have emerged that we don't really _do_.
> 
> "NVR Update Check testing" was requested a long time ago by engineering,
> but never really happened. It's now pretty much superseded by AutoQA
> upgradepath testing, so I think we can delete it from the calendar for
> F17 and later and forget about it.
> 
> "Daily Review & Notification of Open Alpha|Beta|Final Blocker Bugs" is a
> trickier customer. As scheduled, it seems to suggest that for Alpha,
> Beta and Final, we should be 'reviewing and notifying' open blockers for
> an arbitrary-seeming one week (Monday to Friday) period between the
> second and third blocker review meetings.
> 
> So, a few questions:
> 
> 1. Does anyone know where this comes from, and what's the intent behind
> it? CCing John for that purpose.

It comes from a lack of activity and visibility into the issues that
were agreed to be release blocking.  I see this activity as instrumental
in covering the gap between process and people.  The two aren't always
lined up ... and occasional check-ins have proven helpful to flesh out
issues.

> 2. Does anyone think it's a good idea to simply do this as scheduled - a
> daily blocker review for a one-week period in the middle of each release
> phase?

Read below ... it's a good idea to do, we just need to determine how
"official" to make this.

> 3. If 'no' to question 2, do people think we need to do some sort of
> review and notification outside of the blocker meetings and updating the
> bugs themselves? If so, what?

Daily/frequent review of the bugs outside the meeting is an important
activity that I haven't documented very well.  It's something I've been
doing regularly (behind-the-scenes) leading up to each of the important
milestones.  Given the rapid and short release cycle ... I'm convinced
this is a key contributor to releasing on time.  I don't have a hard
script that I follow, but it typically involves me reaching out to
maintainers for feedback/ETA/updates on IRC, bugzilla or email.
Sometimes someone else in #fedora-qa will offer to check-in on a bug.
Either way, this has proven very helpful to re-prioritize resources in
the event a developer is busy, sick or on vacation.  This also helps
flush out any differences in perceived priority between maintainer and
release criteria.

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/20110729/d082cb79/attachment.bin