2009-06-03 - Fedora QA Meeting Recap

Thu Jun 4 12:51:22 UTC 2009

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20090604/3a3d0d50/attachment.bin 