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
Proven testers
During the QA weekly meeting of 2010-06-14[1], Adam Williamson reported that he had drafted a set of instructions[2] for proven testers (under the new proven tester policy[3]), and also had updated various wiki pages[4] [5] [6] to reference the proven testers process. James Laska noted that he was monitoring the ticket[7] requesting the infrastructure team to configure Bodhi to require proven tester feedback on critical path updates. Adam subsequently announced his draft on the mailing list[8], followed by a second draft[9]. Aaron Faanes stepped in[10] with a much-improved revision of Adam's draft[11]. Adam replied[12] to thank Aaron for his improvements.
AutoQA
During the QA meeting, Kamil Paral reported that the AutoQA team had decided to re-prioritize their goals with the aim of delivering concrete results as soon as possible, even where this meant not immediately meeting the whole range of aims for the project[13]. They had decided the current priorities were to test and finish the Bodhi hook, implementing the ability to run potentially dangerous tests in a virtual machine, creating a test instance of the autotest environment for testing new features without breaking the stable instance, getting a publicly accessible machine for the results database (resultdb), and working on resultdb.
- ↑ http://fedoraproject.org/wiki/QA/Meetings/20100614
- ↑ http://fedoraproject.org/wiki/User:Adamwill/Draft_proventesters_instructions
- ↑ http://fedoraproject.org/wiki/QA/JoinProvenTesters
- ↑ http://fedoraproject.org/wiki/QA
- ↑ http://fedoraproject.org/wiki/QA/Join
- ↑ http://fedoraproject.org/wiki/QA/Updates_Testing
- ↑ http://fedorahosted.org/bodhi/ticket/424
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-June/091513.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-June/091552.html
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-June/091559.html
- ↑ https://fedoraproject.org/wiki/User:Dafrito/Draft_proventesters_instructions
- ↑ http://lists.fedoraproject.org/pipermail/test/2010-June/091560.html
- ↑ http://fedorahosted.org/pipermail/autoqa-devel/2010-June/000668.html
Critical path wiki update
James Laska announced[1] that he had revised the critical path documentation on the Wiki. He had created a new page[2] to complement the existing critical path proposal page[3], which had initially been only the proposal of the critical path process but had come to be used as a general reference for the implemented process as well.
Kernel triage
During the Bugzappers weekly meeting of 2010-06-15[1], JP reported that he had updated the stock responses on the older kernel triage page[2] to match the style of the newer Bugzappers stock responses[3], and asked for feedback on the changes.
Triage metrics
During the Bugzappers meeting, Jeff Raber reported his progress on the new triage metrics project. He had created a Bugzilla query[1] which lists bugs triaged in the previous 30 days, and was working on some modifications to python-bugzilla to provide output suited to triage statistics. Adam Williamson promised to put Jeff in touch with Will Woods to discuss merging the python-bugzilla changes.
Setting needinfo on impending end-of-life bugs
During the Bugzappers meeting, Matej Cepl suggested that when adding a comment to bugs on releases that will soon go end-of-life, we should also set the needinfo state to mark that additional input is needed to keep the bug open. After some discussion, everyone agreed that this was a good idea.
Fedora 14 recommendations
James Laska announced[1] the list of recommendations for the Fedora 14 cycle based on the Fedora 13 QA retrospective[2]. He noted that the next task would be to organize the recommendations into a set of trac tickets to track their implementation.
Reopening bugs
Matt McCutchen brought up the topic[1] of reopening bugs, specifically the fact that most Bugzilla users can only reopen bugs that they filed (or which are assigned to them). He mentioned that he had filed an RFE asking that all users be given permission to reopen bugs[2]. Adam Williamson said[3] he would forward the proposal to the Bugzilla maintainers for consideration.