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].
Contributing Writer: Adam Williamson
Test Days
The Fedora 15 Test Day track is now finished, and the Fedora 16 Test Day track has not yet started. If you would like to propose a main track Test Day for the Fedora 16 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac[1].
Fedora 15 validation and preparation
This was a quiet week after the declaration that Fedora 15 was gold on Tuesday, so the group worked on updating the Fedora 15 common bugs page[1] and tried to help with getting the Sugar desktop into a releasable state[2], and made sure 0-day updates for the release were being properly tested. James Laska worked on[3] and announced[4]providing a validation framework for the newly-introduced multi-desktop DVD live image[5], and along with Andre Robatino and Christoph Wickert, performed the required testing.
- ↑ http://fedoraproject.org/wiki/Common_F15_bugs
- ↑ http://bugzilla.redhat.com/show_bug.cgi?id=697649
- ↑ http://fedorahosted.org/fedora-qa/ticket/164#comment:7
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100175.html
- ↑ http://fedoraproject.org/wiki/Test_Results:Fedora_15_Final_Multi_Boot_DVD
Release criteria revisions
Adam Williamson proposed some more release criteria changes. First up was logging[1]. James Laska suggested a refinement[2], and Adam posted a revised proposal[3], which was met with general approval. Later, Adam announced that he had created the criteria pages for Fedora 16[4], and including the new logging criterion, along with some other criteria which had previously been agreed upon but not added to the Fedora 15 criteria. He also re-started the discussion of how to refer to desktops that are considered able to block the release as compared to those that are not, and suggested the term 'release-blocking desktops'. Jóhann Guðmundsson re-raised the question of which desktops should be considered to block the release[5], and Adam maintained that this was a question that was beyond the authority of the QA group to decide[6]. Finally, Adam also proposed a criterion regarding security issues[7] for discussion by the QA group along with the security and development groups.
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100126.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100128.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100131.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100183.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100188.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100189.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2011-May/100237.html
Housekeeping tasks
Adam Williamson noted that there are several tasks nominally under the Bugzappers group's remit that had not been happening recently[1], and suggested running a meeting to ensure they would be looked after. Robyn Bergeron replied that several of the tasks were really her responsibility as program manager[2], but agreed that it would be a good idea to improve the scheduling and planning of these tasks to make it less likely they would not be completed in future.
QA approval of release candidates
Adam Williamson reported[1] that he had updated the Go/No-Go meeting wiki page[2] to define the parameters for QA's approval or otherwise of release candidate builds, to make it clear that QA's decision in this regard is entirely determined by concrete criteria (whether all necessary validation tests have been completed and no unaddressed accepted release blocker bugs remain), so that there is no subjectivity to the decision and it can be reported to the Go/No-Go meeting by any member of the QA group (or simply inferred by anyone present at the meeting, whether a member of the QA team or not). Jóhann Guðmundsson questioned whether the Go/No-Go meeting was even necessary, given the improved procedures[3]. Adam agreed that this was a reasonable question[4], but suggested it might be a good idea to preserve the meeting as a 'human in the loop' safeguard against particularly strange and unforeseeable circumstances.
Triage scripts updated (again!)
Following quickly on the heels of last week's 1.0 RC1, Matej Cepl announced the release of version 1.0 of his Firefox extension to aid in bug triage, bugzilla-triage-scripts[1]. He asked all Bugzappers with Firefox 4 to update to it and report back on how it worked.
AutoQA
The AutoQA team updated their progress as usual at the weekly QA meeting of 2011-05-23[1]. Kamil Paral reported that the team had been working on the proposed 'pretty' plaintext logs, with two proposals: one[2] and two[3]. Tim Flink had been working on the proposed 'spam reduction' code, making AutoQA output less overwhelming for developers, and would be pushing it soon. Josef Skladanka had been working on a wiki page giving an overview of the ResultsDB project[4].