QualityAssurance
In this section, we cover the activities of the QA team[1]. For more information on the work of the QA team and how you can get involved, see the Joining page[2].
The QA section returns this week after a month's absence, for which I apologize! At first I was busy with Fedora 14 Beta work, and for the last two weeks I simply missed the deadline. If anyone would like to help write the QA beat so this doesn't happen in future, please do get in touch, I'd welcome the help.
Contributing Writer: Adam Williamson
Test Days
Since the last issue, there have been Test Days for systemd[1] (recap[2]), anaconda non-English translations and keyboard layouts[3] (recap[4]), virtualization[5], and the Graphics Test Week, including nouveau[6], radeon[7], and intel[8] (recap[9]). See the recaps for details on each event, but they were all broadly successful in exposing bugs to be fixed for the Fedora 14 release.
Next week's Test Day[10] on 2010-10-14 will be on the use of OpenLDAP with the NSS security library - the use of NSS with OpenLDAP is new in Fedora 14, replacing the previous use of OpenSSL. The Test Day will focus on ensuring that OpenLDAP with NSS behaves exactly as OpenLDAP with OpenSSL did. If you're an OpenLDAP user, please come along to the Test Day and help ensure there are no nasty surprises with OpenLDAP in Fedora 14! As always, the Test Day will run all day in the #fedora-test-day IRC channel. You can help out with testing using a virtual machine, so there's no need to alter your main system.
This will be the last Test Day of the Fedora 14 cycle. If you would like to propose a main track Test Day for the Fedora 15 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac[11].
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-07_Systemd
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-September/093463.html
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-16_AnacondaTranslationKeyboard
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-September/093871.html
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-23_Virtualization
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-28_Nouveau
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-29_Radeon
- ↑ http://fedoraproject.org/wiki/Test_Day:2010-09-30_Intel
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-October/094439.html
- ↑ https://fedoraproject.org/wiki/Test_Day:2010-10-14_OpenLDAP/NSS
- ↑ http://fedorahosted.org/fedora-qa/
Fedora 14 Beta testing
The group has been busy for the last month or so with Fedora 14 Beta validation and testing. We performed validation testing on TC1[1], RC1[2], RC2[3] and RC3[4], with many community members contributing extensive testing. Eventually we declared that RC3 had passed installation validation testing and desktop validation testing (including all four primary desktops), and along with the development and release engineering groups, approved the release of RC3 as Fedora 14 Beta at the go/no-go meeting of 2010-09-22[5].
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-September/093468.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-September/093830.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-September/093843.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-September/093947.html
- ↑ http://meetbot.fedoraproject.org/fedora-meeting/2010-09-22/fedora-meeting.2010-09-22-21.01.log.html
Proven testers
Adam Williamson announced[1] a proven testers procedure clarification[2]: if an update does not fix a bug it claims to fix, but otherwise works correctly and has other changes which do work, proven testers should not file negative karma against that update.
Release criteria
James Laska proposed some new release criteria[1] defining when artwork should be ready for each Fedora release. John Dulaney and Adam Williamson responded positively, so James pushed the change to the Wiki[2].
Adam Williamson proposed a new release criterion[3] requiring there to be no unintentional conflicts or unresolved dependencies in the entire package repository frozen for release. This was proposed on behalf of release engineering following discussion at a blocker meeting. Some felt this was too high a standard to aim for. After some discussion, Bill Nottingham stated that "I'd be willing to extend/change this such that trees are tested for broken dependencies, all broken dependencies are filed, and these tickets are attached to the nice-to-have tracker".
Nice-to-have bug process
Adam Williamson submitted a proposal[1] for a formal process for handling nice-to-have bugs; those bugs that do not block a given release but for which fixes will be taken during the freeze period for that release. James Laska responded with some suggested modifications[2].