From Fedora Project Wiki

< FWN‎ | Beats

m (references)
(create fwn 288 draft)
 
(130 intermediate revisions by 4 users not shown)
Line 2: Line 2:
== QualityAssurance ==
== QualityAssurance ==


In this section, we cover the activities of the QA team<ref>http://fedoraproject.org/wiki/QA</ref>.
In this section, we cover the activities of the QA team<ref>http://fedoraproject.org/wiki/QA</ref>. For more information on the work of the QA team and how you can get involved, see the Joining page<ref>http://fedoraproject.org/wiki/QA/Join</ref>.
 
We apologize for the lack of a QA section for the last few issues of FWN: the QA team was very busy with Fedora 16 validation testing. This issue catches up with the QA team news from the last several weeks.


Contributing Writer: [[User:Adamwill|Adam Williamson]]
Contributing Writer: [[User:Adamwill|Adam Williamson]]
Line 10: Line 12:
=== Test Days ===
=== Test Days ===


This week's regular test day<ref>http://fedoraproject.org/wiki/QA/Test_Days/2009-03-05</ref> was on the rewritten handling of storage devices in Anaconda<ref>http://fedoraproject.org/wiki/Features/AnacondaStorageRewrite</ref>. [[User:Dlehman|Dave Lehman]], [[User:Clumens|Chris Lumens]] and [[User:Jgranados|Joel Granados]] were the developers present. Several people showed up and provided valuable testing in a wide range of scenarios, and the developers were able to identify and resolve several bugs. Further testing in this area is still very helpful. The Wiki page contains instructions for using a supplementary image while installing Rawhide, to use the new storage code successfully, but the code will soon be available directly in Rawhide, so testing can be performed simply by attempting to install Rawhide in as many different storage scenarios as possible.
In the past few weeks, we finished up the Fedora 16 Test Day schedule, with Graphics Test Week taking place at the start of September<ref>http://fedoraproject.org/wiki/Test_Day:2011-09-06_Nouveau</ref> ref>http://fedoraproject.org/wiki/Test_Day:2011-09-07_Radeon</ref> ref>http://fedoraproject.org/wiki/Test_Day:2011-09-07_Radeon</ref>, virtualization test day taking place on 2011-09-15<ref>http://fedoraproject.org/wiki/Test_Day:2011-09-15_Virtualization</ref>, another i18n desktop test day on 2011-09-22<ref>http://fedoraproject.org/wiki/Test_Day:2011-09-22_I18n_Desktop</ref>, an ABRT test day on 2011-09-26<ref>http://fedoraproject.org/wiki/Test_Day:2011-09-26_ABRT</ref>, a power management test day on 2011-09-29<ref>http://fedoraproject.org/wiki/Test_Day:2011-09-29_PowerManagement</ref>, printing test day on 2011-10-06<ref>http://fedoraproject.org/wiki/Test_Day:2011-10-06_Printing</ref>, Fedora packager plugin for Eclipse test day on 2011-10-13<ref>http://fedoraproject.org/wiki/Test_Day:2011-10-13_Fedora_Packager_for_Eclipse</ref>, and Cloud SIG test day on 2011-10-20<ref>http://fedoraproject.org/wiki/Test_Day:2011-10-20_Cloud_SIG_Test_Day</ref>. Most of these test days passed off successfully with the work of the developers behind them, despite the QA team being very busy, so many thanks to those who organized and carried out these events, and those who turned up to do the testing.


Next week's test day<ref>http://fedoraproject.org/wiki/QA/Test_Days/2009-03-12</ref> is tentatively scheduled for testing Intel graphics devices, especially the new kernel mode setting support and identifying performance regressions from Fedora 10. It will be held on Thursday (2009-03-12) in the #fedora-qa channel on Freenode IRC. If you use an Intel graphics card, please come by to help make sure it will be well-supported in Fedora 11 - the more testing, the better the code!
The Fedora 17 Test Day cycle has not yet started. We welcome proposals for test days for the Fedora 17 cycle, and we usually accept all the proposals that are made. You can propose a test day for almost anything, and organize it yourself following the handy guide we provide<ref>http://fedoraproject.org/wiki/QA/SOP_Test_Day_management</ref>, or alternatively we can help out with the organization of the event. Information on how to propose a test day is available on the Wiki<ref>http://fedoraproject.org/wiki/QA/Test_Days/Create</ref>.


<references/>
<references/>


=== Weekly meetings ===
=== Fedora 16 preparation ===


The QA group weekly meeting<ref>http://fedoraproject.org/wiki/QA/Meetings</ref> was held on 2009-03-04. The full log is available<ref>http://wwoods.fedorapeople.org/fedora-qa/fedora-qa-20090304.log.html</ref>. [[User:Wwoods|Will Woods]] pointed out that the next week's meeting would be an hour earlier for most people, after the onset of Daylight Savings Time. [[User:Adamwill|Adam Williamson]] and [[User:jkeating|Jesse Keating]], as the resident West Coast representatives, led a revolt against having to wake up at 7 a.m., and the group agreed to move the meetings to 1700UTC from 2009-03-11.
As mentioned above, Fedora 16 release validation took up almost all of the QA team's time during the last few months, with very challenging Beta and Final releases. There were a total of 12 candidate builds for Beta and Final combined, and the whole team put in tireless work running the set of validation tests against each build and then investigating and verifying the large number of blocker bugs identified. The team was able to contribute to the release eventually going ahead with only a one week slip to the Beta schedule and no slip of the Final schedule, a considerable achievement in the light of the many complex changes in the Fedora 16 feature list.


[[User:Jlaska|James Laska]] reported on the progress of the project to make the Semantic test result plugin for mediawiki available. He reported that he is currently trying to make the plugin work in his test setup prior to building a Fedora package for it, as the infrastructure group requires all software used for Fedora systems be available as a Fedora package. [[User:Adamwill|Adam Williamson]] offered to help with the packaging.
<references/>


[[User:Wwoods|Will Woods]] and [[User:jkeating|Jesse Keating]] reported that there had been no progress on the autoqa systems this week, as Jesse had been tied up doing the mass rebuild of Rawhide.
=== Release criteria updates ===


[[User:Wwoods|Will Woods]] reported that 33 of the Fedora 11 proposed features<ref>http://fedoraproject.org/wiki/Releases/11/FeatureList</ref> have not yet been reviewed by the QA group to ensure that they include a workable test plan, and appealed for help from the group in getting this process completed. He noted that features for which test days have already taken place are likely to have workable test plans in place, as these are generally necessary for a test day to happen, so suggested at least those features could be quickly reviewed and, most likely, approved.
Largely as a result of the Fedora 16 validation process, there were several adjustments and additions to the release criteria in recent weeks. After discussion of the proposed kickstart / unattended installation release criterion concluded, [[User:Adamwill|Adam Williamson]] reported that he had committed his proposed modifications<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102599.html</ref>. He also committed a change to reflect the increased priority of EFI installations from Fedora 17 onwards<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102600.html</ref>.


[[User:Adamwill|Adam Williamson]] reported that the test day for the new nouveau driver<ref>http://fedoraproject.org/wiki/Features/NouveauAsDefault</ref> for NVIDIA hardware was already planned and prepared, but that he was waiting on developer replies for the planned Intel KMS<ref>http://fedoraproject.org/wiki/Features/IntelKMS</ref> and automatic fonts and MIME installer<ref>http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller</ref> test days. [[User:Johannbg|Jóhann Guðmundsson]] suggested having a single big graphics test day, but [[User:Adamwill|Adam Williamson]] explained that he did not want to do that as it would be too large and unmanageable. [[User:Jlaska|James Laska]] suggested running the Piglit<ref>http://people.freedesktop.org/~nh/piglit/</ref> OpenGL test suite as part of the test days for drivers with usable 3D support (radeon and intel).
Adam also passed on a suggestion from [[User:Pjones|Peter Jones]] to improve the clarity of the virtualization criteria<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102601.html</ref>. After an extensive discussion, an elegant wording suggestion from Albert Graham<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102636.html</ref> was eventually accepted and committed<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103680.html</ref>.


[[User:jkeating|Jesse Keating]] reported that the mass rebuild of Rawhide was complete. [[User:Adamwill|Adam Williamson]] pointed out that three large bugs had resulted from GCC 4.4 optimization problems after the rebuild, and [[User:Wwoods|Will Woods]] reported that this had been discussed during the release engineering meeting. Will noted that the new hashing system in RPM was not backwards compatible, the upshot being that those upgrading from Fedora 11 Alpha to current Rawhide need to run 'yum update rpm' first. He queried why yum did not automatically update itself and rpm before other packages, and [[User:jkeating|Jesse Keating]] explained it was because this would usually bring in hundreds of other packages via Python and glibc dependencies in any case, and so was not worth the effort.
[[User:Tflink|Tim Flink]] raised the question to what extent support for Xen virtualization should be included in the release criteria<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/103127.html</ref>. After a similarly enthusiastic discussion, it was eventually agreed that Xen DomU support - effectively, the ability to install successfully as a Xen guest - should be a Final release criterion<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103678.html</ref>.


[[User:jkeating|Jesse Keating]] reported that live CD image builds from current Rawhide were not working very well, and Anaconda is often broken while its developers are busy working on the storage rewrite and EFI features.
Adam also proposed downgrading some rarely-used kickstart deployment methods from Beta to Final in the criteria, requiring only the most commonly-used to be working at Beta stage<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103557.html</ref>.


The Bugzappers group weekly meeting<ref>http://fedoraproject.org/wiki/BugZappers/Meetings</ref> was held on 2009-03-03. The full log is available<ref>http://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Mar-03</ref>. The group agreed to make sure the two most important Greasemonkey scripts for triagers were easily available in a central place, and this was implemented by making them available directly from the Wiki Tools page<ref>https://fedoraproject.org/wiki/BugZappers/Tools</ref>.
Finally, Adam proposed a criterion for i18n (translation) issues<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103588.html</ref>. After discussion, the proposal was agreed upon at a blocker review meeting later in the week<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103679.html</ref>.


The group discussed [[User:Beland|Christopher Beland's]] plan to re-organize the Wiki area. It was agreed that a mailing list discussion should take place to create and agree upon a new front page for the Bugzappers wiki area, and work could then progress on re-writing and re-arranging other pages based on the organization system set up by the new front page. The group also discussed and agreed upon a plan for revising the Components page<ref>https://fedoraproject.org/wiki/BugZappers/Components</ref>, and [[User:Beland|Christopher Beland]] pointed out that the current bug flow diagram is incorrect, as it dates from before NEEDINFO was converted from a bug status into a flag. [[User:Tk009|Edward Kirk]] bravely volunteered to fix the picture.
<references/>
 
Finally, the group discussed creating SOPs (Standard Operating Procedures) for Bugzappers, along the lines of those already used by the Infrastructure group. [[User:Poelstra|John Poelstra]] proposed the first SOP cover the procedure for gaining membership in the Bugzappers, and further proposed that it should involve the prospective new member posting a self-introduction email to the mailing list. [[User:Beland|Christopher Beland]] and [[User:Tk009|Edward Kirk]] opposed this as they were worried that some new members would not feel comfortable posting such a message, particularly if it contained personal information. The group agreed to discuss the proposal further on the mailing list.


The next QA weekly meeting will be held on 2009-03-11 at 1700 UTC (note changed time, in UTC reference frame) in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-03-10 at 1700 UTC in #fedora-meeting.
=== Update policy changes ===


<references/>
In September, [[User:Karsten|Karsten Hopp]] raised the issue of a security update for Fedora 14 which had been languishing in the updates-testing repository for some time<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102493.html</ref>. [[User:Adamwill|Adam Williamson]] explained that the amount of testers working on older releases was limited, and that the actual karma requirements for updates to be accepted were controlled by FESCo (the Fedora engineering steering committee), not the QA group<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102497.html</ref>. [[User:Cra|Chuck Anderson]] noted that he had the update in question installed, but was struggling for lack of information on how to test it properly<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102503.html</ref>. [[User:Sundaram|Rahul Sundaram]] suggested that Karsten file a ticket with FESCo to raise the issue<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102502.html</ref>, and Karsten did<ref>http://fedorahosted.org/fesco/ticket/664</ref>.


=== Bugzappers Wiki reorganization ===
That ticket was merged with another similar one reported by Doug Ledford<ref>http://fedorahosted.org/fesco/ticket/667</ref>, which became a topic of concern to FESCo. After several rounds of discussions, FESCo first decided to relax the requirements for critical path updates somewhat by allowing them to be sent through to the stable repository without the 'required' karma after a period of two weeks had elapsed<ref>http://fedorahosted.org/bodhi/ticket/642</ref>, and later proposed removing the requirement for critical path updates to receive positive karma from a proven tester<ref>http://fedorahosted.org/fesco/ticket/667#comment:26</ref>, effectively a proposal to end the proven tester system, as this is the only function it serves.


[[User:Beland|Christopher Beland]] made several proposals<ref>http://www.redhat.com/archives/fedora-test-list/2009-February/msg01223.html</ref> on reorganizing the Bugzappers wiki area. This prompted a long discussion. In the end, Christopher was asked to provide drafts for several of his proposed changes for the group to evaluate. Both Christopher and [[User:Tk009|Edward Kirk]] provided drafts for a new front page. [[User:Adamwill|Adam Williamson]] commented<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00290.html</ref> that both drafts had good elements, and offered to create a new draft to try and combine the two.
The QA group discussed this proposal at the weekly meeting of 2011-11-07<ref>http://fedoraproject.org/wiki/QA/Meetings/20111107</ref>, agreeing that, while they had some reservations about the proposal, they were not definitely opposed to it, and recognized that critical path updates not receiving the currently-required karma is a significant problem.


<references/>
<references/>


=== 20 Second Boot test day follow up ===
=== Update candidate notification ===


[[User:Harald|Harald Hoyer]] posted a follow-up email<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00057.html</ref> on the previously-held 20 Second Boot test day<ref>https://fedoraproject.org/wiki/QA/Test_Days/2009-02-19</ref>, pointing to a blog post<ref>http://www.harald-hoyer.de/personal/blog/20_Seconds_Boot_Feature_Test_Day</ref> where he summarized all the useful data he was able to get from the test day.
Samuel Greenfeld asked if there was any system to notify testers of new candidate updates for specific packages, and to determine what packages are being actively used on a system<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102981.html</ref>. There were no takers for the second question, but for the first, [[User:Adamwill|Adam Williamson]] suggested using yum parameters that would allow one to specify only certain packages be pulled from the updates-testing repository<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102982.html</ref>, and [[User:till|Till Maas]] pointed out that Bodhi can actually provide per-package RSS notifications<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102992.html</ref>.


<references/>
<references/>


=== Bugzappers meeting schedule ===
=== Proven tester meetings ===
 
Lalit Dhiri proposed<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00131.html</ref> having a second meeting to accommodate those whose schedules made it impossible for them to attend the regular group meetings. [[User:Adamwill|Adam Williamson]] said<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00155.html</ref> that was not likely to be practical, but suggested that the meeting time could be moved if a time when more group members would be able to attend could be identified. [[User:laubersm|Susan Lauber]] suggested<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00165.html</ref> using the Wiki's meeting matrix template to handle registering who is available when, and set up a Wiki page<ref>https://fedoraproject.org/wiki/Bugzappers_meeting_matrix</ref> for the purpose.
 
<references/>


=== Ubuntu triage discussion ===
As a response to the concerns about candidate updates not receiving enough karma, [[User:Kevin|Kevin Fenzi]] ran a series of weekly proven tester meetups<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/102869.html</ref> from 2011-09-21 to 2011-10-26. Recaps of these meetings are available in the mailing list archives<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/103000.html</ref> <ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103341.html</ref> <ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103585.html</ref> <ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103840.html</ref> <ref>http://lists.fedoraproject.org/pipermail/test/2011-October/104043.html</ref>.


[[User:Pfrields|Paul Frields]] pointed out<ref>https://www.redhat.com/archives/fedora-test-list/2009-March/msg00211.html</ref> a long discussion on the topic of bug triaging in Ubuntu<ref>http://lwn.net/Articles/321473/</ref>, and wondered what the lessons for the Bugzappers might be. [[User:Adamwill|Adam Williamson]] suggested that it showed it is important for triagers to follow up on bugs they triage, rather than just touching them once and then never returning, which can leave the reporter more frustrated than if the bug had never been triaged at all. In the ensuing discussion, John Summerfield suggested that triagers should try to cover one area of which they had substantial knowledge rather than attempting to cover all bugs in all components<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00312.html</ref>, and that the Bugzappers group should remember actively to involve package maintainers in the triaging process<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00385.html</ref>. [[User:kkofler|Kevin Kofler]] explained<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00393.html</ref> that, within the KDE SIG, maintainers and triagers do work together and communicate via IRC.
Kevin also proposed an updates-testing-info mailing list, containing only the mails about new packages in updates-testing<ref>http://lists.fedoraproject.org/pipermail/test/2011-September/103163.html</ref>. However, the consensus was against the idea, as it was felt that it was easy enough to simply filter the desired mails from the test mailing list for those who did not want to read the other traffic.


<references/>
<references/>


=== Introduction emails ===
=== QA group representation at FUDCon Pune ===


[[User:Adamwill|Adam Williamson]] mooted the proposal from the weekly meeting that introduction emails be required for new group members<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00266.html</ref>. [[User:Poelstra|John Poelstra]] supported the proposal<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00314.html</ref>, as did [[User:Tk009|Edward Kirk]]<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00319.html</ref>. [[User:Beland|Christopher Beland]] suggested<ref>http://www.redhat.com/archives/fedora-test-list/2009-March/msg00341.html</ref>that anyone who became active on the mailing list but did not write a formal self-introduction email should also be accepted.
[[User:Ankursinha|Ankur Sinha]] asked whether anyone from the QA team would be present at the upcoming FUDCon in Pune, India and able to do a presentation on the group's activities<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103712.html</ref>. [[User:Adamwill|Adam Williamson]] replied that unfortunately none of the Red Hat team would be at the conference, but encouraged Ankur to take a shot at giving a presentation himself<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103728.html</ref>. A S Alam then stepped up to volunteer to lead a QA session<ref>http://lists.fedoraproject.org/pipermail/test/2011-October/103739.html</ref>. His session was scheduled for 2011-11-04<ref>http://fudcon.in/sessions/fedora-testing</ref>, but we have no report on the event - if you were present, please write to the mailing list and let us know how it went!


<references/>
<references/>

Latest revision as of 05:10, 17 November 2011

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].

We apologize for the lack of a QA section for the last few issues of FWN: the QA team was very busy with Fedora 16 validation testing. This issue catches up with the QA team news from the last several weeks.

Contributing Writer: Adam Williamson

Test Days

In the past few weeks, we finished up the Fedora 16 Test Day schedule, with Graphics Test Week taking place at the start of September[1] ref>http://fedoraproject.org/wiki/Test_Day:2011-09-07_Radeon</ref> ref>http://fedoraproject.org/wiki/Test_Day:2011-09-07_Radeon</ref>, virtualization test day taking place on 2011-09-15[2], another i18n desktop test day on 2011-09-22[3], an ABRT test day on 2011-09-26[4], a power management test day on 2011-09-29[5], printing test day on 2011-10-06[6], Fedora packager plugin for Eclipse test day on 2011-10-13[7], and Cloud SIG test day on 2011-10-20[8]. Most of these test days passed off successfully with the work of the developers behind them, despite the QA team being very busy, so many thanks to those who organized and carried out these events, and those who turned up to do the testing.

The Fedora 17 Test Day cycle has not yet started. We welcome proposals for test days for the Fedora 17 cycle, and we usually accept all the proposals that are made. You can propose a test day for almost anything, and organize it yourself following the handy guide we provide[9], or alternatively we can help out with the organization of the event. Information on how to propose a test day is available on the Wiki[10].

Fedora 16 preparation

As mentioned above, Fedora 16 release validation took up almost all of the QA team's time during the last few months, with very challenging Beta and Final releases. There were a total of 12 candidate builds for Beta and Final combined, and the whole team put in tireless work running the set of validation tests against each build and then investigating and verifying the large number of blocker bugs identified. The team was able to contribute to the release eventually going ahead with only a one week slip to the Beta schedule and no slip of the Final schedule, a considerable achievement in the light of the many complex changes in the Fedora 16 feature list.


Release criteria updates

Largely as a result of the Fedora 16 validation process, there were several adjustments and additions to the release criteria in recent weeks. After discussion of the proposed kickstart / unattended installation release criterion concluded, Adam Williamson reported that he had committed his proposed modifications[1]. He also committed a change to reflect the increased priority of EFI installations from Fedora 17 onwards[2].

Adam also passed on a suggestion from Peter Jones to improve the clarity of the virtualization criteria[3]. After an extensive discussion, an elegant wording suggestion from Albert Graham[4] was eventually accepted and committed[5].

Tim Flink raised the question to what extent support for Xen virtualization should be included in the release criteria[6]. After a similarly enthusiastic discussion, it was eventually agreed that Xen DomU support - effectively, the ability to install successfully as a Xen guest - should be a Final release criterion[7].

Adam also proposed downgrading some rarely-used kickstart deployment methods from Beta to Final in the criteria, requiring only the most commonly-used to be working at Beta stage[8].

Finally, Adam proposed a criterion for i18n (translation) issues[9]. After discussion, the proposal was agreed upon at a blocker review meeting later in the week[10].

Update policy changes

In September, Karsten Hopp raised the issue of a security update for Fedora 14 which had been languishing in the updates-testing repository for some time[1]. Adam Williamson explained that the amount of testers working on older releases was limited, and that the actual karma requirements for updates to be accepted were controlled by FESCo (the Fedora engineering steering committee), not the QA group[2]. Chuck Anderson noted that he had the update in question installed, but was struggling for lack of information on how to test it properly[3]. Rahul Sundaram suggested that Karsten file a ticket with FESCo to raise the issue[4], and Karsten did[5].

That ticket was merged with another similar one reported by Doug Ledford[6], which became a topic of concern to FESCo. After several rounds of discussions, FESCo first decided to relax the requirements for critical path updates somewhat by allowing them to be sent through to the stable repository without the 'required' karma after a period of two weeks had elapsed[7], and later proposed removing the requirement for critical path updates to receive positive karma from a proven tester[8], effectively a proposal to end the proven tester system, as this is the only function it serves.

The QA group discussed this proposal at the weekly meeting of 2011-11-07[9], agreeing that, while they had some reservations about the proposal, they were not definitely opposed to it, and recognized that critical path updates not receiving the currently-required karma is a significant problem.

Update candidate notification

Samuel Greenfeld asked if there was any system to notify testers of new candidate updates for specific packages, and to determine what packages are being actively used on a system[1]. There were no takers for the second question, but for the first, Adam Williamson suggested using yum parameters that would allow one to specify only certain packages be pulled from the updates-testing repository[2], and Till Maas pointed out that Bodhi can actually provide per-package RSS notifications[3].

Proven tester meetings

As a response to the concerns about candidate updates not receiving enough karma, Kevin Fenzi ran a series of weekly proven tester meetups[1] from 2011-09-21 to 2011-10-26. Recaps of these meetings are available in the mailing list archives[2] [3] [4] [5] [6].

Kevin also proposed an updates-testing-info mailing list, containing only the mails about new packages in updates-testing[7]. However, the consensus was against the idea, as it was felt that it was easy enough to simply filter the desired mails from the test mailing list for those who did not want to read the other traffic.

QA group representation at FUDCon Pune

Ankur Sinha asked whether anyone from the QA team would be present at the upcoming FUDCon in Pune, India and able to do a presentation on the group's activities[1]. Adam Williamson replied that unfortunately none of the Red Hat team would be at the conference, but encouraged Ankur to take a shot at giving a presentation himself[2]. A S Alam then stepped up to volunteer to lead a QA session[3]. His session was scheduled for 2011-11-04[4], but we have no report on the event - if you were present, please write to the mailing list and let us know how it went!