mNo edit summary |
(create draft for fwn 174) |
||
| Line 10: | Line 10: | ||
=== Test Days === | === Test Days === | ||
This week | This week's Test Day<ref>http://fedoraproject.org/wiki/Test_Day:2009-04-30</ref> was on SSSD<ref>http://fedoraproject.org/wiki/Features/SSSD</ref>, which provide a set of daemons to manage access to remote directories and authentication mechanisms. A good group of interested people turned out to help test the system, and several bug reports were filed. | ||
Next week's Test Day<ref> | Next week's Test Day<ref>http://fedoraproject.org/wiki/Test_Day:2009-05-07_Virtualization</ref> will be on virtualization<ref>http://fedoraproject.org/wiki/Virtualization</ref>, with a particular emphasis on some of the new features in Fedora 11, mainly to do with KVM. The Test Day page already includes a list of test areas, with estimated test times and the number of testers needed for each area, so you can sign yourself up in the list in preparation for the test day. You will need an installed system fully updated to latest Rawhide (you can start by installing the Fedora 11 Preview release). If you're a virtualization enthusiast, please come along and help test! The Test Day will be held on 2009-05-07 (Thursday) in IRC #fedora-qa. | ||
<references/> | <references/> | ||
| Line 18: | Line 18: | ||
=== Weekly meetings === | === Weekly meetings === | ||
The QA group weekly meeting<ref>http://fedoraproject.org/wiki/QA/Meetings</ref> was held on 2009-04- | The QA group weekly meeting<ref>http://fedoraproject.org/wiki/QA/Meetings</ref> was held on 2009-04-29. The full log is available<ref>http://www.happyassassin.net/extras/fedora-qa-20090429.log</ref>. [[User:Adamwill|Adam Williamson]] reported on his request for feedback on PulseAudio in Fedora 11 from the forum community. He said the response had been quite small and had not reported any major problems, a good indication that things are quite solid. [[User:Wwoods|Will Woods]] mentioned that the known problems with some Intel chipsets and PA's glitch-free audio feature had now been mostly resolved. | ||
[[User: | [[User:Jlaska|James Laska]] noted that there were several reports indicating the new hard disk failure detection system may be reporting false positives. The group agreed it should keep an eye on this situation and try to determine for certain whether there were bugs in the detection. | ||
[[User: | [[User:Wwoods|Will Woods]] reported on autoqa progress. A trac installation for autoqa is now available<ref>http://fedorahosted.org/autoqa/</ref>, but there has been no progress in the code since next week. [[User:Jlaska|James Laska]] suggested setting a goal of finishing the previously agreed-upon to-do list by the time of Fedora 11's release, and Will agreed that this was a sensible target. | ||
Will also reported on a planned new version of preupgrade, the tool for helping do smooth in-place upgrades of Fedora systems. It now attempts to find updated versions of all repositories, including third-party ones, and rejects /boot on mdraid. | |||
The | The group then discussed the state of the Fedora 11 blocker bug list, with reference to the impending Fedora 11 RC cycle. They agreed that 2009-05-11 and 2009-05-12 would be set aside for review of the list, divided by component, with each team member working on components with which they are familiar. | ||
The group | The group then discussed upgrade methods, with regard to a bug<ref>https://bugzilla.redhat.com/show_bug.cgi?id=494046</ref> noted by Seth Vidal which would essentially prevent an in-place upgrade using yum from working correctly. [[User:Wwoods|Will Woods]] reiterated that yum-based upgrading is intentionally undocumented and unsupported (i.e. yum's developer does not consider that it should be expected to work, FESco does not expect package maintainers to build their packages such that it works, and QA does not accept responsibility for ensuring it works). The intended method for doing such upgrades is to use the preupgrade tool. | ||
[[User:Jlaska|James Laska]] mentioned that he was looking for volunteers to help organize test cases for the upcoming virtualization Test Day<ref>http://fedoraproject.org/wiki/Test_Day:2009-05-07_Virtualization</ref>. Please contact James if you're interested in helping out with this. | |||
The next QA weekly meeting will be held on 2009- | The Bugzappers group weekly meeting<ref>http://fedoraproject.org/wiki/BugZappers/Meetings</ref> was held on 2009-04-28. The full log is available<ref>http://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Apr-28</ref>. [[User:poelstra|John Poelstra]] noted that, as the Fedora 11 release nears, it is time for the group to request the regularly scheduled Bugzilla changes that accompany a new release. John then selflessly volunteered to take care of this, with the help of [[User:Arxs|Niels Haase]]. | ||
In the absence of Brennan Ashton, [[User:Adamwill|Adam Williamson]] reported on the progress of the triage metrics project, having met with Brennan the previous weekend. He reported that the code for the project was essentially complete and hosting via the Infrastructure group had already been provisioned, but the code relied on Python 2.5-specific features, while Infrastructure's servers all run Python 2.4. Thus the project was waiting on Brennan, or someone else, to port the Python 2.5-specific code to Python 2.4 before it could be operational. | |||
Adam also reported on the status of the Bugzilla priority/severity proposal, and noted he was nearly ready to send the proposal to the development group. | |||
[[User:poelstra|John Poelstra]] reported that the maintainers of the Red Hat Bugzilla installation were interested in feedback from the Bugzappers group on what proposed new features and fixes for Bugzilla would be of most interest to them. He promised to send relevant URLs to the mailing list. | |||
The next QA weekly meeting will be held on 2009-05-06 at 1600 UTC in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-05-05 at 1500 UTC in #fedora-meeting. | |||
<references/> | |||
=== Special triage procedure requests from developers === | |||
The Bugzappers group continued its discussion of how to handle special triage procedure requests from maintainers (which was started<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg01418.html</ref> the previous week by [[User:Adamwill|Adam Williamson]]). Adam continued to maintain that all special requests from maintainers should be respected if at all possible, as the triage process exists almost entirely to aid maintainers in their work. [[User:poelstra|John Poelstra]] worried<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg01605.html</ref> that it may be impossible to accurately track all the different special requests that maintainers might make, a position backed up<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg01623.html</ref> by John Summerfield. [[User:Beland|Christopher Beland]] felt<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg01607.html</ref> that special requests have a cost in terms of recruiting triagers and performing system-wide tasks. [[User:kkofler|Kevin Kofler]] suggested<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg01671.html</ref> an alternative system that might work without varying the standard triage process for the particular special request that had started the discussion, and pointed out that in the current process, the NEW, ASSIGNED and ON_DEV statuses are essentially being abused. No final agreement was reached on the various topics brooched as of yet, and it seems the issue might feed back into the problem of shared bug workflow between Fedora and RHEL. | |||
<references/> | |||
=== Priority / severity proposal draft === | |||
[[User:Adamwill|Adam Williamson]] submitted<ref>http://www.redhat.com/archives/fedora-test-list/2009-May/msg00021.html</ref> a revised proposed draft of the email to the development list on the use of the priority and severity fields in Bugzilla, addressing the concerns raised since the previous draft, and including Matej Cepl's alternative proposal. | |||
<references/> | <references/> | ||
Revision as of 17:49, 3 May 2009
QualityAssurance
In this section, we cover the activities of the QA team[1].
Contributing Writer: Adam Williamson
Test Days
This week's Test Day[1] was on SSSD[2], which provide a set of daemons to manage access to remote directories and authentication mechanisms. A good group of interested people turned out to help test the system, and several bug reports were filed.
Next week's Test Day[3] will be on virtualization[4], with a particular emphasis on some of the new features in Fedora 11, mainly to do with KVM. The Test Day page already includes a list of test areas, with estimated test times and the number of testers needed for each area, so you can sign yourself up in the list in preparation for the test day. You will need an installed system fully updated to latest Rawhide (you can start by installing the Fedora 11 Preview release). If you're a virtualization enthusiast, please come along and help test! The Test Day will be held on 2009-05-07 (Thursday) in IRC #fedora-qa.
Weekly meetings
The QA group weekly meeting[1] was held on 2009-04-29. The full log is available[2]. Adam Williamson reported on his request for feedback on PulseAudio in Fedora 11 from the forum community. He said the response had been quite small and had not reported any major problems, a good indication that things are quite solid. Will Woods mentioned that the known problems with some Intel chipsets and PA's glitch-free audio feature had now been mostly resolved.
James Laska noted that there were several reports indicating the new hard disk failure detection system may be reporting false positives. The group agreed it should keep an eye on this situation and try to determine for certain whether there were bugs in the detection.
Will Woods reported on autoqa progress. A trac installation for autoqa is now available[3], but there has been no progress in the code since next week. James Laska suggested setting a goal of finishing the previously agreed-upon to-do list by the time of Fedora 11's release, and Will agreed that this was a sensible target.
Will also reported on a planned new version of preupgrade, the tool for helping do smooth in-place upgrades of Fedora systems. It now attempts to find updated versions of all repositories, including third-party ones, and rejects /boot on mdraid.
The group then discussed the state of the Fedora 11 blocker bug list, with reference to the impending Fedora 11 RC cycle. They agreed that 2009-05-11 and 2009-05-12 would be set aside for review of the list, divided by component, with each team member working on components with which they are familiar.
The group then discussed upgrade methods, with regard to a bug[4] noted by Seth Vidal which would essentially prevent an in-place upgrade using yum from working correctly. Will Woods reiterated that yum-based upgrading is intentionally undocumented and unsupported (i.e. yum's developer does not consider that it should be expected to work, FESco does not expect package maintainers to build their packages such that it works, and QA does not accept responsibility for ensuring it works). The intended method for doing such upgrades is to use the preupgrade tool.
James Laska mentioned that he was looking for volunteers to help organize test cases for the upcoming virtualization Test Day[5]. Please contact James if you're interested in helping out with this.
The Bugzappers group weekly meeting[6] was held on 2009-04-28. The full log is available[7]. John Poelstra noted that, as the Fedora 11 release nears, it is time for the group to request the regularly scheduled Bugzilla changes that accompany a new release. John then selflessly volunteered to take care of this, with the help of Niels Haase.
In the absence of Brennan Ashton, Adam Williamson reported on the progress of the triage metrics project, having met with Brennan the previous weekend. He reported that the code for the project was essentially complete and hosting via the Infrastructure group had already been provisioned, but the code relied on Python 2.5-specific features, while Infrastructure's servers all run Python 2.4. Thus the project was waiting on Brennan, or someone else, to port the Python 2.5-specific code to Python 2.4 before it could be operational.
Adam also reported on the status of the Bugzilla priority/severity proposal, and noted he was nearly ready to send the proposal to the development group.
John Poelstra reported that the maintainers of the Red Hat Bugzilla installation were interested in feedback from the Bugzappers group on what proposed new features and fixes for Bugzilla would be of most interest to them. He promised to send relevant URLs to the mailing list.
The next QA weekly meeting will be held on 2009-05-06 at 1600 UTC in #fedora-meeting, and the next Bugzappers weekly meeting on 2009-05-05 at 1500 UTC in #fedora-meeting.
- ↑ http://fedoraproject.org/wiki/QA/Meetings
- ↑ http://www.happyassassin.net/extras/fedora-qa-20090429.log
- ↑ http://fedorahosted.org/autoqa/
- ↑ https://bugzilla.redhat.com/show_bug.cgi?id=494046
- ↑ http://fedoraproject.org/wiki/Test_Day:2009-05-07_Virtualization
- ↑ http://fedoraproject.org/wiki/BugZappers/Meetings
- ↑ http://fedoraproject.org/wiki/BugZappers/Meetings/Minutes-2009-Apr-28
Special triage procedure requests from developers
The Bugzappers group continued its discussion of how to handle special triage procedure requests from maintainers (which was started[1] the previous week by Adam Williamson). Adam continued to maintain that all special requests from maintainers should be respected if at all possible, as the triage process exists almost entirely to aid maintainers in their work. John Poelstra worried[2] that it may be impossible to accurately track all the different special requests that maintainers might make, a position backed up[3] by John Summerfield. Christopher Beland felt[4] that special requests have a cost in terms of recruiting triagers and performing system-wide tasks. Kevin Kofler suggested[5] an alternative system that might work without varying the standard triage process for the particular special request that had started the discussion, and pointed out that in the current process, the NEW, ASSIGNED and ON_DEV statuses are essentially being abused. No final agreement was reached on the various topics brooched as of yet, and it seems the issue might feed back into the problem of shared bug workflow between Fedora and RHEL.
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg01418.html
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg01605.html
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg01623.html
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg01607.html
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg01671.html
Priority / severity proposal draft
Adam Williamson submitted[1] a revised proposed draft of the email to the development list on the use of the priority and severity fields in Bugzilla, addressing the concerns raised since the previous draft, and including Matej Cepl's alternative proposal.