Full IRC transcript available at https://fedoraproject.org/wiki/QA/Meetings/20090603
= Attendees =
* Adam Williamson (adamw) * Will Woods (wwoods) * Jóhann Guðmundsson (viking_ice) * John Poelstra (poelcat) * James Laska (jlaska) * Jesse Keating (f13) * Paul Frields (stickster)
= Agenda =
== Previous meeting follow-up ==
# [adamw] - BugStatusWorkFlow - ask bugzilla guys to add a link from the bugzilla fields description page to the wiki page, for fedora #* Completed (see {{bz|495985}}), waiting for bugzilla code update during next outage window for changes to go live # [jlaska] - Send informal test day feedback survey to fedora-test-list and test day participants #* [https://www.redhat.com/archives/fedora-test-list/2009-June/msg00160.html Survey] sent to participants and to fedora-test-list # [wwoods] - create preupgrade test case and update test matrix template #* Test cases created (see [[QA:Testcase_Preupgrade]] and [[QA:Testcase_Preupgrade_from_older_release]]) and added to [[QA:Fedora_11_Install_Results_Template]] for any future test matrices # [jlaska] - create new RC1 test results page #* Several pages created to track test results, including: [[QA:Fedora_11_RC0_Install_Test_Results]], [[QA:Fedora_11_RC1_Install_Test_Results]], [[QA:Fedora_11_RC2_Install_Test_Results]], [[QA:Fedora_11_RC3_Install_Test_Results]] # [adamw] - create common bug entry for {{bz|502077}} #* Done and could probably be removed now (see [[Common_F11_bugs#865-hangs]]) since newer kernel resolves the problem
== F-11-GA Preparation ==
* Blocker bugs (by component) - http://tinyurl.com/pqeq6n (currently '''0''' OPEN issues) * Schedule - http://fedoraproject.org/wiki/Releases/11/Schedule * Installation test results - [[QA:Fedora_11_RC4_Install_Test_Results]]
Adamw noted that the new test results wiki page wasn't created yet. Jlaska indicated it would be created soon after the meeting, once he received notification that RC4 composition had completed.
f13 indicated that he will continue to upload more RC4 bits as they are created (live images remain).
jlaska provided an update on RC test results. The [[QA:Fedora_11_RC3_Install_Test_Results|RC3]] results are looking fairly good (when combined with [[QA:Fedora_11_RC0_Install_Test_Results|RC0]], [[QA:Fedora_11_RC1_Install_Test_Results|RC1]], [[QA:Fedora_11_RC2_Install_Test_Results|RC2]]). Once initial scrubbing of RC4 media kits has completed, jlaska asked if attention could be made to verify the 9 MODIFIED bugs on the [http://tinyurl.com/pqeq6n F11 blocker list].
As indicated in the [[Releases/11/Schedule]], staging will begin Thu Jun 4.
jlaska asked if {{bz|503824}} (anaconda-maint-list, NEW, x86_64 upgrade in KVM hangs (OOM) with 512MB RAM + encrypted root_) should be added to the common bugs page. Wwoods indicated that he would confirm on bare metal hardware first, and that this might be a candidate for common bugs. Further discussion began around whether Fedora has a minimal system requirements list. For additional comments, see ''open discussion'' below.
== F-11 QA Post-mortem discussion ==
Jlaska indicated that a release-wide post-mortem review has been discussed for F11, and that he would like to begin the brainstorming around QA-specific topics. For example, what went well, and what needed improvement from a QA perspective.
jlaska had to step out, adamw lead the brainstorming.
Highlights ...
* <wwoods> the test days were awesome. part of my brain says that a) we should only accept features that we can plan test days for, and b) large-scale changes to the video drivers count a feature
* <f13> We need to be better about promoting things to the BLOCKER lists and allowing the review board of folks to take them off the list as necessary we saw too many things slip through because somebody was afraid to make it a blocker
* <adamw> for e.g., while i was pushing the i8x5 opengl issue, krh was working on a text corruption bug that affected all chipsets...which i wasn't aware of because he hadn't marked it blocker (and neither had anyone else) * <adamw> so we obviously haven't yet spread the gospel of marking things as blockers
* <poelcat> review the blocker lists farther in advance of freezes and releases
* <poelcat> clarify/document the handoff process between release engineering and QA of content to be tested clarify/document expectations around when said content needs to be tested by
* <poelcat> more transparency around the decision to slip the release or not... public discussion or at least meeting notes
* <poelcat> try to get a better idea of how many people test each test release
* <poelcat> i think it would be interesting to have a rough idea what kind of "testing community" we have and if it is growing or shrinking
* <wwoods> so yes, you could probably put together a very rough guess of how many people are following rawhide.
* <wwoods> ideally I'd like to have a notion of our usable capacity to test and limit the number of accepted features based on that
* <f13> better rallying around NEEDSRETESTING
* <Viking-Ice> As I replied to devel today maintainers need to user better the resource they have at their disposal fedora-test-list along with QA trac instance
* <adamw> so encouraging maintainers to use QA as a resource they can call upon, yep
* <wwoods> I mentioned test days already... testopia was nice while we had it
* <Viking-Ice> One thing I've discussed with jlaska about is not holding a test day for something that depends on other thing that's broken like hey we schedueled a Gnome Test day but X is not working
* <wwoods> the lesson there, I think, is that we need to leave a couple of test day slots open for rescheduling like leaving room in the school schedule for snow day make-up
* <adamw> and try to schedule ones which rely on a more complex pile of components till a later (and hopefully stabler) point in the cycle and we should continue to start trying to build live CDs several days before the test day, so we're not screwed if it happens to be broken just for one day
* <wwoods> "more autoqa" would be very, very good * <adamw> yeah, definitely just to take autoqa on its own - autoqa is awesome and we need as much of it as possible :)
* <adamw> right...for this meeting, we can say, we would definitely benefit from proper test case management, the f11 cycle did show us that.
= Open discussion =
== What are Fedora minimal requirements? ==
wwoods is seeing an OOM kill issue on a x86_64 KVM guest when upgrading from F10 -> F11 with only 512Mb of memory.
Everyone noted there isn't a clear definition of what minimal system requirements are for Fedora. Adamw directed folks to the bug he and Rahul filed {{bz|499585}}.
= Upcoming QA meetings/events =
* 2009-06-09 - [[BugZappers/Triage_days]] * 2009-06-10 16:00 UTC - Next QA Meeting [[QA/Meetings/20090610]]
= Action items =
[stickster] - who will be handling release_notes bugs to help with {{bz| 499585}} [adamw] - propose draft wording of minimal requirements for the release_notes team to digest