From Fedora Project Wiki

< FWN‎ | Beats

Revision as of 18:04, 28 April 2010 by Adamwill (talk | contribs) (create fwn 223 qa beat)

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

Last week's Test Day[1] was on Anaconda (the Fedora installer)'s storage support[2]. The turnout was unfortunately low, perhaps due to the hardware requirements for testing, but nevertheless the few testers present managed to expose four bugs.

This week will see the final two Test Days of the Fedora 13 cycle. First up is Preupgrade Test Day[3] on Thursday 2010-04-29, followed by Xfce Test Day[4] on Friday 2010-04-30.

These are two juicy topics: preupgrade[5] is the recommended method for upgrading from one Fedora release to the next, and Xfce is one of the most popular 'alternate' Linux desktops, and has a very dedicated Fedora SIG[6] which works hard to provide a smooth experience and live spin, and has organized the Test Day to make sure the Fedora 13 Xfce experience is second to none.

As always, the Test Days will run all day in the #fedora-test-day channel on Freenode IRC. If you're not sure about IRC, read the guide or use WebIRC[7]. If you can't do the testing on the Test Day, you can still run through the tests and provide your results earlier or later. You can do the Xfce testing with a live image which will be provided on the Test Day page. Obviously this isn't possible for the preupgrade testing, but you can test it in a virtual machine if you don't want to (or can't) mess with your real Fedora installation.

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

Update acceptance testing

At the weekly QA meeting[1], Adam Miller asked if a vote would be needed to move ahead with the proventesters policy he was drafting. Adam Williamson said votes were not normally needed and suggested just sending a final draft to the mailing list with a note that it would go into effect if there were no major objections. Adam Miller subsequently sent the final draft to the list[2], where Adam Williamson[3], Shmuel Siegel[4] and others suggested small amendments, which Adam Miller accepted[5].

Kamil Paral reported that the package update acceptance test plan[6] could be completed before the end of the Fedora 13 cycle, for automation and implementation in the Fedora 14 cycle. Kamil later posted a final call for comments[7] on the plan, to which James Laska[8] and Jesse Keating[9] provided detailed responses.

Remote accessibility release criterion proposal

Adam Williamson proposed[1] a new release criterion stating that it must be possible to install a system in such a way that it is immediately remotely accessible. This was in response to reports on the list that it was not possible to do this in Fedora 13, in contrast to previous releases, which was causing sysadmins dealing with remote machines some problems.

Fedora 11 end-of-life notification

John Poelstra announced[1] that he would soon send out the end-of-life notification for Fedora 11 on bugs reported against that release. Jason Tibbitts noted[2] that he had adjusted open package review requests filed against that release, so these would not erroneously receive notifications.

Fedora 13 testing

This week saw the second blocker bug review meeting[1] for the final release. The group reviewed all open blocker bugs with assistance from the development team; in general, progress is being made on all blockers and we don't foresee any major problems resolving them in time for release.

Al Dunsmuir reported[2] a crash in Firefox with the common Noscript extension when browsing the release notes, which he filed as a bug[3].

Joachim Backes reported[4] a problem booting to runlevel 3 with the echoing of login information: he had seen cases where the username was not echoed back to the screen when typed, but the password was (obviously, the behavior should be opposite). Steven I Usdansky confirmed[5] that he had seen a similar issue.