(missed a references tag) |
(fwn 207 beat in) |
||
| Line 16: | Line 16: | ||
=== Weekly meetings === | === Weekly meetings === | ||
The QA group weekly meeting<ref>http://fedoraproject.org/wiki/QA/Meetings</ref> was held on 2009-12-14. The full log is available<ref>http://fedoraproject.org/wiki/QA/Meetings/20091214</ref>. [[User:Adamwill|Adam Williamson]] reported that the note on hardware-dependent issues as relating to the release criteria which he had promised to write was done, and added to the blocker bug FAQ<ref>http://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F</ref>. | |||
[[User:Jlaska|James Laska]] reported that he was still working on a list of recommendations based on the Fedora 12 retrospective, but expected to have it finished within the next few days. | |||
[[User: | [[User:Adamwill|Adam Williamson]] gave an update on the release criteria improvement process. As planned, a group had gathered to finalize work on the new criteria at FUDCon, and the new criteria were now officially in place<ref>http://fedoraproject.org/wiki/Fedora_Release_Criteria</ref>. No-one felt there was significant additional work to do on the criteria themselves for the Fedora 13 cycle. | ||
[[User:Adamwill|Adam Williamson]] gave | [[User:Adamwill|Adam Williamson]] gave an update on the privilege escalation policy topic. He had not received any practical feedback or suggestions from the Red Hat security group, so intended to escalate the issue to FESCo without an actual proposed policy. [[User:Wwoods|Will Woods]] noted that he had had some discussions at FUDCon about how to implement AutoQA tests for builds which added or removed setuid binaries, consolehelper configuration files, or PolicyKit policies. | ||
[[User: | [[User:Wwoods|Will Woods]] and [[User:Kparal|Kamil Paral]] reported on the progress of the AutoQA project. Will mentioned that he had given a talk on AutoQA at FUDCon, and pointed to the slides<ref>http://wwoods.fedorapeople.org/files/AutoQA-FUDCon-Toronto-2009.odp</ref>. He had returned with several good ideas for future improvements to AutoQA suggested by other participants, and a clearer plan for implementing the much-needed dependency checking test. Kamil said that he had been working on integrating rpmguard as an AutoQA test, and this initial work was available in the 'kparal/rpmguard-integration' git branch. He had posted an email announcement<ref>http://fedorahosted.org/pipermail/autoqa-devel/2009-December/000047.html</ref> of this, containing some example output. | ||
[[User: | [[User:Jlaska|James Laska]] noted the work [User:Rhe|Rui He]] and [[User:Liam|Liam Li]] had been doing on the 'is anaconda broken?' proposal<ref>http://fedoraproject.org/wiki/Is_anaconda_broken_proposal</ref>. He also said he was planning a release sprint to revise the release validation test plans for the new release criteria. | ||
The Bugzappers group weekly meeting<ref>http://fedoraproject.org/wiki/BugZappers/Meetings</ref> was held on 2009-12-15. The full log is available<ref>http://meetbot.fedoraproject.org/fedora-meeting/2009-12-15/fedora-meeting.2009-12-15-15.18.log.html</ref>. [[User:Mcepl|Matej Cepl]] reported that he was planning to replace the current GreaseMonkey script used to enhance Bugzilla pages for the benefit of triagers with Jetpacks<ref>http://jetpack.mozillalabs.com/</ref>. He asked for volunteers to test the initial versions of the Jetpacks, available from his space<ref>http://mcepl.fedorapeople.org/scripts/install.html</ref>. | |||
The next QA weekly meeting will be held on 2009-12-21 at 1600 UTC in #fedora-meeting. The next Bugzappers weekly meeting will be held on 2009-12-22 at 1500 UTC in #fedora-meeting. | |||
The next QA weekly meeting | |||
<references/> | <references/> | ||
=== | === Increasing the grub timeout === | ||
Scott Robbins started a long thread<ref>http://www.redhat.com/archives/fedora-test-list/2009-November/msg01012.html</ref> with the suggestion to increase the default timeout for the Fedora boot loader from its current default setting of 0 (which causes the boot loader menu never to be shown at all). There were many opinions on this idea, but the general response was positive enough for Scott to file a feature request<ref>http://bugzilla.redhat.com/show_bug.cgi?id=541315</ref> on the idea, where some compromises were suggested. Richard Ryniker suggested having the system detect unclean shutdowns and force the boot menu to be displayed on the next boot (much as Windows does). Stewart Adam suggested having grub initially installed with a non-zero timeout, and have firstboot change it to zero on the assumption that a system that can get to firstboot must have a properly configured bootloader. | |||
<references/> | <references/> | ||
=== | === X.org server testing === | ||
[[User: | [[User:Adamwill|Adam Williamson]] posted a request<ref>http://www.redhat.com/archives/fedora-test-list/2009-December/msg00278.html</ref> for group members to test a recent Fedora 12 X.org server build provided by the Fedora X development team, to provide some assurance that it worked acceptably before it would be submitted as a candidate update. Many members submitted useful reports in response, with a generally positive character. However, one potential issue with the nouveau driver emerged thanks to the report of Mike Chambers<ref>http://www.redhat.com/archives/fedora-test-list/2009-December/msg00305.html</ref>, and was passed back to the developers for investigation. | ||
<references/> | <references/> | ||
Revision as of 20:53, 18 December 2009
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, and no Test Day is currently planned for this week. If you would like to propose a main track Test Day for the Fedora 13 cycle, 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-12-14. The full log is available[2]. Adam Williamson reported that the note on hardware-dependent issues as relating to the release criteria which he had promised to write was done, and added to the blocker bug FAQ[3].
James Laska reported that he was still working on a list of recommendations based on the Fedora 12 retrospective, but expected to have it finished within the next few days.
Adam Williamson gave an update on the release criteria improvement process. As planned, a group had gathered to finalize work on the new criteria at FUDCon, and the new criteria were now officially in place[4]. No-one felt there was significant additional work to do on the criteria themselves for the Fedora 13 cycle.
Adam Williamson gave an update on the privilege escalation policy topic. He had not received any practical feedback or suggestions from the Red Hat security group, so intended to escalate the issue to FESCo without an actual proposed policy. Will Woods noted that he had had some discussions at FUDCon about how to implement AutoQA tests for builds which added or removed setuid binaries, consolehelper configuration files, or PolicyKit policies.
Will Woods and Kamil Paral reported on the progress of the AutoQA project. Will mentioned that he had given a talk on AutoQA at FUDCon, and pointed to the slides[5]. He had returned with several good ideas for future improvements to AutoQA suggested by other participants, and a clearer plan for implementing the much-needed dependency checking test. Kamil said that he had been working on integrating rpmguard as an AutoQA test, and this initial work was available in the 'kparal/rpmguard-integration' git branch. He had posted an email announcement[6] of this, containing some example output.
James Laska noted the work [User:Rhe|Rui He]] and Liam Li had been doing on the 'is anaconda broken?' proposal[7]. He also said he was planning a release sprint to revise the release validation test plans for the new release criteria.
The Bugzappers group weekly meeting[8] was held on 2009-12-15. The full log is available[9]. Matej Cepl reported that he was planning to replace the current GreaseMonkey script used to enhance Bugzilla pages for the benefit of triagers with Jetpacks[10]. He asked for volunteers to test the initial versions of the Jetpacks, available from his space[11].
The next QA weekly meeting will be held on 2009-12-21 at 1600 UTC in #fedora-meeting. The next Bugzappers weekly meeting will be held on 2009-12-22 at 1500 UTC in #fedora-meeting.
- ↑ http://fedoraproject.org/wiki/QA/Meetings
- ↑ http://fedoraproject.org/wiki/QA/Meetings/20091214
- ↑ http://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F
- ↑ http://fedoraproject.org/wiki/Fedora_Release_Criteria
- ↑ http://wwoods.fedorapeople.org/files/AutoQA-FUDCon-Toronto-2009.odp
- ↑ http://fedorahosted.org/pipermail/autoqa-devel/2009-December/000047.html
- ↑ http://fedoraproject.org/wiki/Is_anaconda_broken_proposal
- ↑ http://fedoraproject.org/wiki/BugZappers/Meetings
- ↑ http://meetbot.fedoraproject.org/fedora-meeting/2009-12-15/fedora-meeting.2009-12-15-15.18.log.html
- ↑ http://jetpack.mozillalabs.com/
- ↑ http://mcepl.fedorapeople.org/scripts/install.html
Increasing the grub timeout
Scott Robbins started a long thread[1] with the suggestion to increase the default timeout for the Fedora boot loader from its current default setting of 0 (which causes the boot loader menu never to be shown at all). There were many opinions on this idea, but the general response was positive enough for Scott to file a feature request[2] on the idea, where some compromises were suggested. Richard Ryniker suggested having the system detect unclean shutdowns and force the boot menu to be displayed on the next boot (much as Windows does). Stewart Adam suggested having grub initially installed with a non-zero timeout, and have firstboot change it to zero on the assumption that a system that can get to firstboot must have a properly configured bootloader.
X.org server testing
Adam Williamson posted a request[1] for group members to test a recent Fedora 12 X.org server build provided by the Fedora X development team, to provide some assurance that it worked acceptably before it would be submitted as a candidate update. Many members submitted useful reports in response, with a generally positive character. However, one potential issue with the nouveau driver emerged thanks to the report of Mike Chambers[2], and was passed back to the developers for investigation.