QA/Meetings/20091123

= Attendees =

People present (lines said)


 * jlaska (140)
 * adamw (73)
 * wwoods (68)
 * Oxf13 (39)
 * poelcat (26)
 * Viking-Ice (21)
 * kparal (20)
 * spot (7)
 * tibbs (2)
 * zodbot (2)
 * jwb (2)
 * buggbot (1)
 * tk009 (1)
 * pjones (1)
 * jeff_hann (1)

Regrets:
 * User:Liam
 * User:rhe

= Agenda =


 * Proposed meeting agenda
 * meetbot summary

Previous meeting follow-up

 * jlaska will propose Common_F12_Bugs after meeting for bug#530541

Added to the list with help from User:wwoods and User:adamw (See Common_F12_bugs). Also reorganized How_to_use_PreUpgrade and we've had several additional contributions to the troubleshooting section from User:Toshio and User:Mccann.


 * preupgrade test updates

Per last weeks FESCO meeting on preupgrade, QA team took an action item to update the preupgrade test cases (QA:Testcase Preupgrade and QA:Testcase Preupgrade from older release). Fedora QA trac ticket#30 is tracking this update. User:rhe and User:Kparal have adding their thoughts to the issue.


 * jlaska to send request for retrospective feedback to fedora-test-list@

Unfortunately, no action this past week. Will prioritize for this week and discuss next week.

Security Test Plan
Spot posted some great points around non-root user security expectations in his blog last week (see http://spot.livejournal.com/312216.html). This seems to me like an interesting project worth pursuing for Fedora 13.

The team discussed at length, highlights include:


 * Spot updated his blog with the latest feedback from his blog -- see http://spot.livejournal.com/312216.html
 * part#1 - Should involve defining a security policy ... instead of making one up
 * This policy may take into account a method for each spin SIG to add spin-specific security policy.
 * part#2 - The QA team can support a security policy by creating test documentation (plans/cases) and providing test results

AdamW agreed to take the first step by initiating discussion with fedora-devel-list and fedora-security-list to begin the process of reaching consensus on a security policy.

Enhancing Release Criteria
John Poelstra has been thinking about enhancements to the current Fedora release criteria and has organized his thoughts into several wiki pages, starting with Fedora_Release_Criteria. There aren't intentions that this list will be the end-all be-all of checklists for the list. I know we've all experienced some of the subjective nature of identifying blocker bugs and assessing release impact.

Please take a few moments to review the criteria, along with the following pages, and offer your suggestions/corrections.

Fedora 13 release criteria
 * Fedora_13_Alpha_Release_Criteria
 * Fedora_13_Beta_Release_Criteria
 * Fedora_13_Final_Release_Criteria

General FAQ around escalating blocker bugs - Blocker_Bug_FAQ

User:poelstra joined the meeting and recommended reading the email announcement first. John also indicated he was hoping this would set a better stage for more info that might come from the target audience discussion. The plan was to host healthy discussion on the mailing list until FUDCon. Then, at FUDCon, hammer out the dents and formalize something we can use for Fedora 13. John asked the team if this was realistic. Adamw and jlaska felt it was.

Wwoods noted that the original release criteria was started by writing down whatever unwritten common-sense tests and policies we already had, and maybe a couple "it'd be nice if.." ones. John thanked Will for starting the release criteria process, as many of the points raised in the original page are included in the new release-specific pages.

wwoods updates
autoqa-0.3 merged into the master branch (see http://git.fedorahosted.org/git/?p=autoqa.git;a=commit;h=a27a03f527a76af24bac46dd3872efc9fd4e3984). This branch adds:
 * a new autoqa python library
 * which includes, shared repoinfo code for the watcher scripts and utility functions/classes for tests
 * the new post-koji-build hook. Which is still fairly experimental, but we have it running a simple 'rpmlint' test on every new build that comes out of koji

Wwoods outlined several FUDCon plans, including:
 * An info session on current and future plans
 * A hackfest on a solid depcheck test
 * Work to solidify the post-koji-build hook
 * Think of some possible ways to make it easy for package maintainers to add post-build tests
 * Get rpmguard up and running

kparal asked how work was proceed with running autoqa locally (see ticket#52). Wwoods indicated that was a prerequisite for maintainers to be able to work on post-build tests

kparal updates
While waiting for wwoods' big merge (52 commits ahead), I was trying to improve wiki documentation. So I created a new AutoQA front page (see AutoQA), which should work as a guidepost - different kinds of user can choose interesting stuff for them and go to a link for details. The previous content was moved to "AutoQA architecture" page. there's the post: https://fedorahosted.org/pipermail/autoqa-devel/2009-November/000023.html. Kamil advised ... not to look at the front page much in detail, it's going to change soon. Jlaska proposed an improved version for review at User:Jlaska/Draft which may replace the current version soon.

Kamil's plan for this week includes working on integration of rpmguard into autoqa. Wwoods noted that they'd need to figure out what to do with the output of the test (mail it to package owners/autoqa-results?) and what to do when there's a change that should block the package. But that can wait until after the test is working.

Misc

 * Use cases - https://fedoraproject.org/wiki/AutoQA_Use_Cases - INPROGRESS
 * Packaging autotest - https://fedorahosted.org/autoqa/ticket/9 - DONE
 * Packaging autoqa - https://fedorahosted.org/autoqa/ticket/3 - DONE
 * Convert israwhidebroken to WSGI - https://fedorahosted.org/autoqa/ticket/91 - INPROGRESS

FUDCon - Oxf13
Jkeating announced plans to host a talk around the future of Fedora development. This talk would include outlining No_Frozen_Rawhide_Proposal, AutoQA, auto-signing, new milestones, and how all these puzzle pieces are supposed to fit together.

Jwb asked if the discussion could be recorded for those who would not be in attendance.

Target audience for DVD.iso - Viking-Ice
In reference to the Fedora target audience discussion, Viking-Ice asked, ''Who's the dvd img target audience. sysadmins [ or ] end users?''

Jlaska pointed to the install guide which states: If you have plenty of time, a fast Internet connection, and wish a broader choice of  software on the install media, download the full DVD version

Wwoods provided a link to the fedora-advisory-board discussion - http://lwn.net/Articles/358865/

Discussion followed around whether DVD/CD optical media was still required. The recommendation was to take any updates or discussion on this topic to the fedora-advisory-board list.

= Upcoming QA events =


 * NA

= Action items =


 * adamw - initiate security policy discussion on fedora-{devel,security}-list
 * jlaska to send request for retrospective feedback to fedora-test-list@

= IRC transcript =

Generated by irclog2html.py 2.7 by [mailto:marius@pov.lt Marius Gedminas] - find it at mg.pov.lt!