[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 2009-06-17 - Fedora QA meeting Agenda



James Laska said the following on 06/16/2009 12:23 PM Pacific Time:
Fedora QA Meeting
Date: 2009-06-17
Time: 16:00 UTC (12 EDT)
Location: #fedora-meeting on irc.freenode.net

         1. Previous meeting follow-up ...
         https://fedoraproject.org/wiki/QA/Meetings/20090610

         2. F-11 retrospective feedback

         3. QA feedback of related FAD topics

         4. AutoQA - the wheels are in motion


I have a conflict and will not be able to attend tomorrow.

5. There have been a few different conversations about adding more granularity to the schedule, more blocker bug days, and making the hand-off between releng and QA clearer.

I've taken a shot at doing that here:
http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html
(right now releng is the most detailed and complete... I'll create other team schedules for QA, etc. after we get the kinks out of this one.)

Key take-aways:

1) Blocker bug reviews happen on Fridays before key freezes
2) Exact date of releng composes are specified... hopefully this makes it easier to plan ahead.
3) Exact dates of testing of releng composes by QA are specified
4) Composes are scheduled the day following a freeze (tuesday). Naturally there can be multiple composes, but I am guessing that with limited resource, QA can only commit to testing certain ones vs. every compose that shows up. I think this gets at the points raised, but if it doesn't let me know and I'll put the dates and tasks on the schedule a different way. 5) For all releases, including GA, there are two composes with time scheduled to test them.

Open Questions:
1) What tweaks should I make to better reflect QA's needs?
2) What tweaks should I make to better reflect releng's needs (I'm assuming Jesse will be there). 3) What contingencies should we document and intact if composes are late, testing isn't finished, or tests fail?

Now that we have matured and have a larger QA presence I think we should move to more of a standard software model (just as we did with the naming of the schedule, etc.) where there is more separation between Releng and QA. IOW, Releng provides the service of packing the bits and composing an installable distro and QA provides the service of testing them and giving a thumbs up/down on them.

John


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]