2009-06-17 - Fedora QA meeting Agenda

[John Poelstra]

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