From Fedora Project Wiki

< FWN‎ | Beats

(doh.)
(create fwn 220 qa beat)
Line 2: Line 2:
== QualityAssurance ==
== QualityAssurance ==


In this section, we cover the activities of the QA team<ref>http://fedoraproject.org/wiki/QA</ref>. This week, we are trying out a new topic-focused layout, without the topic-by-topic weekly meeting recaps. Please let [[User:Adamwill|me]] know if you particularly like or dislike the new layout!
In this section, we cover the activities of the QA team<ref>http://fedoraproject.org/wiki/QA</ref>. It seems like the new layout has been a success, so we'll stick with it for the future.


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


Last week's Test Day<ref>http://fedoraproject.org/wiki/Test_Day:2010-03-25_Printing</ref> was on printing, including the implementation of automatic print driver installation<ref>http://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation</ref>in Fedora 13. There was a disappointingly low turnout, despite [[User:twaugh|Tim Waugh's]] extensive efforts to organize and promote the event. We theorize that printing works so well for most people that they didn't think it was necessary to turn up! Nevertheless, thanks to those who did come out to test, and reported five bugs for Tim to work on.
We had two Test Days last week. The first<ref>http://fedoraproject.org/wiki/Test_Day:2010-03-30_SSSDByDefault</ref>, on Tuesday 2010-03-30, was on the implementation of SSSD by default<ref>http://fedoraproject.org/wiki/Features/SSSDByDefault</ref>. This feature is very useful to those who use accounts on a remote server which may not always be accessible from their system. A small group of dedicated testers were able to expose five bugs, which the developers are now investigating. The second<ref>http://fedoraproject.org/wiki/Test_Day:2010-04-01_ABRT</ref> was on ABRT<ref>http://fedoraproject.org/wiki/Features/ABRT</ref>, the automated bug report tool which has been included with Fedora by default since the release of Fedora 12. This event resulted in mostly positive test results, but also exposed six bugs, three of which have already been closed by the developers.


This week sees two Test Days. The first<ref>http://fedoraproject.org/wiki/Test_Day:2010-03-30_SSSDByDefault</ref>, on Tuesday 2010-03-30, will have passed by the time you read this; it will have been on the implementation of SSSD by default<ref>http://fedoraproject.org/wiki/Features/SSSDByDefault</ref>. This feature is very useful to those who use accounts on a remote server which may not always be accessible from their system. We'll bring you a report on this event next week.
This week's Test Day<ref>https://fedoraproject.org/wiki/Test_Day:2010-04-08_Virtualization</ref>, on Thursday 2010-04-08, will be on virtualization<ref>http://fedoraproject.org/wiki/Virtualization</ref>. This is mainly focused on the Fedora virtualization stack, based around KVM, libvirt, and virt-manager. There've been many improvements throughout the stack for Fedora 13, so there's a lot of new stuff to test as well as making sure the basic functions are working properly. Virtualization is a very important area these days, so please come out to help us test it! The event will take place all day in the #fedora-test-day channel on Freenode IRC. If you can't make it on the day, you can still provide your results on the Wiki page before or after the event.
 
The second<ref>http://fedoraproject.org/wiki/Test_Day:2010-04-01_ABRT</ref> will be on ABRT<ref>http://fedoraproject.org/wiki/Features/ABRT</ref>, the automated bug report tool which has been included with Fedora by default since the release of Fedora 12. We'll be testing Fedora 13 enhancements to ABRT and making sure the system is working correctly for the upcoming Fedora 13 release. ABRT is important to all Fedora users and developers, so if you have a few minutes, please come along and help test! As usual, you can test with an installed Fedora 13 or Rawhide system, or a live image which is available on the Test Day page. [[User:Zprikryl|Zdenek Prikryl]], [[User:Jmoskovc|Jiri Moskovc]] and [[User:Adamwill|Adam Williamson]] will be on hand during the event, which will run all day on Thursday 2010-04-01 in the #fedora-test-day IRC channel.


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<ref>http://fedorahosted.org/fedora-qa/</ref>.
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<ref>http://fedorahosted.org/fedora-qa/</ref>.
Line 22: Line 20:
=== Fedora 13 testing ===
=== Fedora 13 testing ===


The first test compose for Fedora 13 Beta was announced<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089526.html</ref> by [[User:Rhe|Rui He]] on 2010-03-23. The group helped to fill out the planned installation<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_TC1_Install</ref> and desktop<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_TC1_Desktop</ref> test matrices. [[User:Rhe|Rui He]] provided a summary<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089681.html</ref> of the TC test results. Shortly after the test compose, the first release candidate build followed<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089680.html</ref> on 2010-03-26. Andre Robatino provided delta ISOs between TC1 and RC1<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089684.html</ref>. Again, the group quickly filled out the desktop<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_RC1_Desktop</ref> and install<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_RC1_Install</ref> matrices. The testers found several blocker issues.
Once again, the week was occupied with much testing of Fedora 13 Beta candidate builds. The second release candidate was announced<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089807.html</ref> on Wednesday 2010-03-31, and closely followed by the third release candidate on the same day<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089826.html</ref>. As usual, Andre Robatino provided delta ISOs<ref>http://lists.fedoraproject.org/pipermail/test/2010-April/089833.html</ref>. Installation validation testing on RC3<ref>http://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_RC3_Install</ref> revealed a blocker bug in support for encrypted partitions<ref>http://bugzilla.redhat.com/show_bug.cgi?id=578633</ref>. This led the group, along with release engineering and development groups, to take the decision to delay the Beta release by a week<ref>http://lists.fedoraproject.org/pipermail/test/2010-April/089828.html</ref>.
 
The third blocker bug review meeting for Fedora 13 Beta was held on 2010-03-26<ref>http://meetbot.fedoraproject.org/fedora-bugzappers/2010-03-26/f-13-beta-blocker-review.2010-03-26-16.05.html</ref>. All outstanding Beta blocker bugs were reviewed, and developers were consulted on the remaining open bugs to ensure fixes should be available in time for the release candidate process to begin the following week.
 
'John H' reported<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089584.html</ref> that the test candidate build failed to install correctly to an Intel X25-M SSD. [[User:Jlaska|James Laska]] suggested<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089595.html</ref> he file a bug report on the issue.
 
[[User:Kparal|Kamil Paral]], Joachim Backes<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089715.html</ref> and others found a bug<ref>http://bugzilla.redhat.com/show_bug.cgi?id=577789</ref> which prevented the boot process from completing successfully with the Plymouth graphical boot system enabled. The bug was later tracked down and resolved in a build which will be brought into the second Beta release candidate.


<references/>
<references/>
Line 34: Line 26:
=== Update acceptance testing ===
=== Update acceptance testing ===


During the weekly QA meeting<ref>http://fedoraproject.org/wiki/QA/Meetings/20100322</ref>, the group discussed the status of the various proposed changes and policies regarding updates. [[User:Adamwill|Adam Williamson]] summarized that "we need: a policy/sop for the 'proventesters' group, and a guide to providing updates-testing feedback for a) branched and b) stable releases, explaining what actually should be tested and how feedback should be given". [[User:maxamillion|Adam Miller]] provided<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089764.html</ref> a second draft of the proventesters SOP proposal, and [[User:Adamwill|Adam Williamson]] posted a discussion of testing procedure<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089690.html</ref> which posited that a policy for testing updates was impossible within the current Bodhi system, and the best way forward would be to revise the way Bodhi works. [[User:Bochecha|Mathieu Bridon]] pointed out<ref>http://lists.fedoraproject.org/pipermail/devel/2010-March/134089.html</ref> that Williamson's proposal was very similar to Doug Ledford's earlier proposal<ref>http://lists.fedoraproject.org/pipermail/devel/2010-March/131799.html</ref>, and explained that the infrastructure team was already working Doug's ideas into their plans for 'Bodhi 2', the next major revision of Bodhi.
[[User:maxamillion|Adam Miller]] revised his proventesters SOP proposal<ref>http://fedoraproject.org/wiki/QA/JoinProvenTesters:Draft</ref> based on feedback received from [[User:Adamwill|Adam Williamson]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089801.html</ref> and [[User:jkeating|Jesse Keating]]<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089780.html</ref>.
 
<references/>
 
=== Target bug trackers ===
 
Following on from discussion the previous week, [[User:Adamwill|Adam Williamson]] posted a proposal<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089575.html</ref> on the use of the Target bug trackers, suggesting either discontinuing their use or repurposing them to track bugs which did not constitute release blockers, but for which fixes would be accepted through release freezes. The thread turned into quite a wide-ranging discussion about freeze procedures and update acceptance. Later, Adam summarized by suggesting the key issue to decide is 'whether we want to have a time-defined stage' where only fixes for blockers and certain specifically chosen bugs would be accepted, and if a tracker bug is the most sensible way to keep track of those bugs<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089664.html</ref>.


<references/>
<references/>


=== Bugzapping in the classroom ===
=== Stock response for ABRT symbol failures ===


[[User:Vedranm|Vedran Miletić]] asked the group<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089589.html</ref> for advice and support on teaching Bugzapping in a university environment. [[User:Beland|Christopher Beland]] applauded the idea, and suggested Firefox, Evolution, Nautilus and Rhythmbox as good components for a class group to work on. [[User:Adamwill|Adam Williamson]] offered<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089604.html</ref> to provide support and assistance.
[[User:Beland|Christopher Beland]] proposed<ref>http://lists.fedoraproject.org/pipermail/test/2010-April/089875.html</ref> a BugZappers stock response for the situation where ABRT fails to download the packages to provide debugging symbols in an automatically-generated bug report. After receiving no objections, he later reported<ref>http://lists.fedoraproject.org/pipermail/test/2010-April/089902.html</ref> that he had added this to the page<ref>http://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_Debugging_Symbols</ref>.


<references/>
<references/>


=== rsync for test builds ===
=== BugZapping classes ===


Andre Robatino asked<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089669.html</ref> if it would be possible to set up rsync access for the server on which test builds are stored, to make it easier to convert a DVD build into a multi-CD build for testing purposes. He then suggested<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089735.html</ref> that zsync would serve the purpose even better. [[User:Adamwill|Adam Williamson]] pointed out<ref>http://lists.fedoraproject.org/pipermail/test/2010-March/089798.html</ref> that zsync was still not packaged in Fedora due to a problem with bundled libraries.
During the weekly BugZappers meeting<ref>http://meetbot.fedoraproject.org/fedora-meeting/2010-03-30/fedora-meeting.2010-03-30-15.00.log.html</ref>, the group discussed the possibility of providing more ways for new members to get started. [[User:campbecg|Chris Campbell]] volunteered to look into the possibility of running a test Bugzapping class. [[User:Shakthimaan|Shakthi Kannan]] suggested creating screencasts as examples of each step in the triage process, and [[User:Adamwill|Adam Williamson]] said he would forward this idea to the mailing list.


<references/>
<references/>

Revision as of 00:00, 7 April 2010

QualityAssurance

In this section, we cover the activities of the QA team[1]. It seems like the new layout has been a success, so we'll stick with it for the future.

Contributing Writer: Adam Williamson

Test Days

We had two Test Days last week. The first[1], on Tuesday 2010-03-30, was on the implementation of SSSD by default[2]. This feature is very useful to those who use accounts on a remote server which may not always be accessible from their system. A small group of dedicated testers were able to expose five bugs, which the developers are now investigating. The second[3] was on ABRT[4], the automated bug report tool which has been included with Fedora by default since the release of Fedora 12. This event resulted in mostly positive test results, but also exposed six bugs, three of which have already been closed by the developers.

This week's Test Day[5], on Thursday 2010-04-08, will be on virtualization[6]. This is mainly focused on the Fedora virtualization stack, based around KVM, libvirt, and virt-manager. There've been many improvements throughout the stack for Fedora 13, so there's a lot of new stuff to test as well as making sure the basic functions are working properly. Virtualization is a very important area these days, so please come out to help us test it! The event will take place all day in the #fedora-test-day channel on Freenode IRC. If you can't make it on the day, you can still provide your results on the Wiki page before or after the event.

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

Fedora 13 testing

Once again, the week was occupied with much testing of Fedora 13 Beta candidate builds. The second release candidate was announced[1] on Wednesday 2010-03-31, and closely followed by the third release candidate on the same day[2]. As usual, Andre Robatino provided delta ISOs[3]. Installation validation testing on RC3[4] revealed a blocker bug in support for encrypted partitions[5]. This led the group, along with release engineering and development groups, to take the decision to delay the Beta release by a week[6].

Update acceptance testing

Adam Miller revised his proventesters SOP proposal[1] based on feedback received from Adam Williamson[2] and Jesse Keating[3].

Stock response for ABRT symbol failures

Christopher Beland proposed[1] a BugZappers stock response for the situation where ABRT fails to download the packages to provide debugging symbols in an automatically-generated bug report. After receiving no objections, he later reported[2] that he had added this to the page[3].

BugZapping classes

During the weekly BugZappers meeting[1], the group discussed the possibility of providing more ways for new members to get started. Chris Campbell volunteered to look into the possibility of running a test Bugzapping class. Shakthi Kannan suggested creating screencasts as examples of each step in the triage process, and Adam Williamson said he would forward this idea to the mailing list.