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
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
