From Fedora Project Wiki

< FWN‎ | Beats

No edit summary
(create fwn 257 qa beat)
Line 14: Line 14:
<references/>
<references/>


=== Hands-on Bugzapping session at FOSS.in ===
=== Refining Bugzilla messages on updated packages ===


[[User:Siddhesh|Siddhesh Poyarekar]] announced his intention<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/095926.html</ref> to run a hands-on introduction to bug triage at FOSS.in<ref>http://foss.in/</ref>, a major F/OSS event in India. The event will take place during the Fedora mini-conference on 2010-12-16. [[User:Sundaram|Rahul Sundaram]] will help him with this effort<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/095927.html</ref>.
[[User:Fcami|François Cami]] posted a refined version of his Bodhi patch<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096017.html</ref> which improves the messages it posts to Bugzilla when an update is sent to updates-testing and then to stable. The updated patch reflects feedback from other team members at QA meetings.


<references/>
<references/>


=== Bugzappers meeting time change ===
=== Test case management system proposal and requirements ===


At the first Bugzappers meeting for a while<ref>http://meetbot.fedoraproject.org/fedora-meeting/2010-12-07/fedora-meeting.2010-12-07-21.04.html</ref>, the group agreed that in the future, meetings would be held bi-weekly from 2011-01-11, at 21:00 UTC.
[[User:Rhe|Rui He]] has been working on the possibility of implementing a test case management system (TCMS) for Fedora. This is being tracked in a trac ticket<ref>http://fedorahosted.org/fedora-qa/ticket/152</ref> and she has now started drafting the requirements any TCMS would have to satisfy to replace the use of the Fedora Wiki to store test cases<ref>http://fedoraproject.org/wiki/Rhe/tcms_requirements_proposal</ref>.


<references/>
<references/>


=== Bugzappers component prioritization ===
=== AutoQA ===


Also at the Bugzappers meeting, the group agreed it would be beneficial to look at which of the critical path components (the packages Bugzappers aim to work on with the most priority) are actually very commonly subject to bug reports which require triage, and prioritize those components, listing them on the components page<ref>http://fedoraproject.org/wiki/BugZappers/Components_and_Triagers</ref> in a separate table, to make it easier for new triagers to pick a component which will be practical to work on. Andrew Roth volunteered to work on this.
Work on AutoQA continues to progress apace - there is much more than I am able to reliably relay in these newsletters, those who are very interested are recommended to follow the mailing list<ref>http://fedorahosted.org/mailman/listinfo/autoqa-devel</ref>. The anaconda storage tests contributed by [[User:Clumens|Chris Lumens]] have been reviewed and are ready for merging<ref>http://fedorahosted.org/pipermail/autoqa-devel/2010-December/001422.html</ref>. Martin Krizek's patch for allowing results to be reported to Bodhi<ref>http://fedorahosted.org/pipermail/autoqa-devel/2010-December/001411.html</ref> has been reviewed and accepted<ref>http://fedorahosted.org/autoqa/changeset/5d37e59128c1913946c02e6a1d899a5576f37801</ref>. Martin and [[User:Kparal|Kamil Paral]] have been working on implementing a staging server for results, and [[User:Wwoods|Will Woods]] continues to work on dependency check testing. He has now decided to serialize dependency check tests to avoid the complexity involved in supporting parallel tests, having worked out that even at the busiest point, dependency check testing will only be needed, on average, once every 33 minutes.
 
<references/>
 
=== Consequences of negative karma ===
 
[[User:bsjones|Brendan Jones]] asked about the consequences of negative karma, wondering whether test updates he filed negative karma against should be immediately un-pushed, or prevented from being sent to the stable update repository<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096057.html</ref>. [[User:Kevin|Kevin Fenzi]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096058.html</ref> and [[User:Adamwill|Adam Williamson]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096059.html</ref> both explained that negative feedback was considered advisory in nature, and maintainers are able to push updates despite the existence of negative feedback, if they believe it is proper to do so. They both suggested that Brendan could alert FESCo if he felt a packager was ignoring negative feedback inappropriately. Brendan replied that he had asked only for clarification, and did not feel the cases in question were inappropriate<ref>http://lists.fedoraproject.org/pipermail/test/2010-December/096060.html</ref>.


<references/>
<references/>

Revision as of 17:19, 22 December 2010

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 calendar is starting to take shape, and you can see what events are planned so far on the Wiki page[1]. The first Test Day slot is 2011-01-27. 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[2].

Refining Bugzilla messages on updated packages

François Cami posted a refined version of his Bodhi patch[1] which improves the messages it posts to Bugzilla when an update is sent to updates-testing and then to stable. The updated patch reflects feedback from other team members at QA meetings.

Test case management system proposal and requirements

Rui He has been working on the possibility of implementing a test case management system (TCMS) for Fedora. This is being tracked in a trac ticket[1] and she has now started drafting the requirements any TCMS would have to satisfy to replace the use of the Fedora Wiki to store test cases[2].

AutoQA

Work on AutoQA continues to progress apace - there is much more than I am able to reliably relay in these newsletters, those who are very interested are recommended to follow the mailing list[1]. The anaconda storage tests contributed by Chris Lumens have been reviewed and are ready for merging[2]. Martin Krizek's patch for allowing results to be reported to Bodhi[3] has been reviewed and accepted[4]. Martin and Kamil Paral have been working on implementing a staging server for results, and Will Woods continues to work on dependency check testing. He has now decided to serialize dependency check tests to avoid the complexity involved in supporting parallel tests, having worked out that even at the busiest point, dependency check testing will only be needed, on average, once every 33 minutes.

Consequences of negative karma

Brendan Jones asked about the consequences of negative karma, wondering whether test updates he filed negative karma against should be immediately un-pushed, or prevented from being sent to the stable update repository[1]. Kevin Fenzi[2] and Adam Williamson[3] both explained that negative feedback was considered advisory in nature, and maintainers are able to push updates despite the existence of negative feedback, if they believe it is proper to do so. They both suggested that Brendan could alert FESCo if he felt a packager was ignoring negative feedback inappropriately. Brendan replied that he had asked only for clarification, and did not feel the cases in question were inappropriate[4].