QualityAssurance
In this section, we cover the activities of the QA team[1].
Contributing Writer: Adam Williamson
Test Days
There was no Test Day last week.
Currently, no Test Day is scheduled for next week - it is still very early in the Fedora 12 cycle. If you would like to propose a test day which could result in changes for post-release updates for Fedora 11, or an early test day for Fedora 12, please contact the QA team via email or IRC, or file a ticket in QA Trac[1].
Weekly meetings
The QA group weekly meeting[1] was held on 2009-06-24. The full log is available[2]. James Laska reported that he had not yet been able to update the QA Goals page[3], due to lack of time.
Will Woods provided an update on the Rawhide acceptance test plan. The plan is now available on the Wiki[4], with ten suggested test cases. Tickets have been filed to track the creation of each test case. He asked for anyone who was interested in this project to help write or review the test cases. Jóhann Guðmundsson suggested adding a test case for basic network functionality, and the others present agreed with this suggestion.
James Laska reviewed the new schedule for Fedora 12 QA events which has been submitted by John Poelstra[5]. He pointed out several changes he felt were positive. The group discussed whether Test Day dates should be added to the main QA schedule, but in the end decided they should not be.
Will Woods gave a quick further update on the status of AutoQA (which includes the rawhide acceptance testing discussed earlier). He explained that, once the test plans were written, it should be relatively easy to automate them via autotest, and automation of some tests should be complete in one or two weeks. James Laska noted that Jesse Keating had sent a link to a presentation he would be giving on AutoQACite error: Closing </ref> missing for <ref> tag, and asked for feedback to be sent to the list.
Finally, Jóhann Guðmundsson proposed a project to improve the quality and quantity of information contained in bug reports[6]. Will Woods noted that abrt[7], the automated bug reporting tool, will allow the use of plugins to configure what files or other information should be attached to reports from particular components.
The Bugzappers group weekly meeting[8] was held on 2009-06-23. The full log is available[9].
The meeting was dominated by a discussion of the status of the project to integrate anaconda triage better into the BugZappers process, and to introduce kernel triage. Andy Lindeberg and Peter Jones provided valuable information on the anaconda process. After much discussion, it was broadly agreed that there was no broad incompatibility between the anaconda bug process and the BugZappers process, and with a small amount of work, the two could be integrated: a good list of required information for anaconda bug reports should be created, it should be made clear that anaconda reports must be assigned to a specific anaconda maintainer and this assignment confirmed in person via IRC or email before being made, and volunteers to triage anaconda should already be well versed in its workings, or receive some training before beginning to triage actively.
The next QA weekly meeting will be held on 2009-06-31 at 1600 UTC in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-06-30 at 1500 UTC in #fedora-meeting.
- ↑ http://fedoraproject.org/wiki/QA/Meetings
- ↑ http://fedoraproject.org/wiki/QA/Meetings/20090624
- ↑ http://fedoraproject.org/wiki/QA/Goals
- ↑ http://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-June/msg00507.html
- ↑ http://fedoraproject.org/wiki/User:Johannbg/QA/Improve_reporting
- ↑ https://fedorahosted.org/abrt/wiki
- ↑ http://fedoraproject.org/wiki/BugZappers/Meetings
- ↑ http://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Jun-23
Test Day shepherding SOP draft
Adam Williamson announced[1] a draft SOP for the process of running a Test Day[2], with the intent of making it easier for more people to run Test Day events.
Improvement of debugging procedure pages
The recap mail for the QA meeting provoked a thread[1]about the best way to improve the quality of information contained in bug reports. Eventually, several members of the group decided to improve existing pages explaining how to accurately identify and categorize bugs, and what information to include when reporting them, for various components. Work started with the page on X.org[2]. François Cami made some initial improvements[3], Christopher Beland followed these up with some further tweaks and suggestions[4], and Adam Williamson contributed some further additions and addressed Christopher's suggestions.