QA/Meetings/20091130

Agenda

• Proposed meeting agenda
• [FIXME meetbot summary]

Previous meeting follow-up

• adamw - initiate security policy discussion on fedora-{devel,security}-list (see http://spot.livejournal.com/312216.html)
• jlaska to send request for retrospective feedback to fedora-test-list@

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.

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.

Fedora 12 QA retrospective

• See announcement - https://www.redhat.com/archives/fedora-test-list/2009-November/msg01126.html
• See wiki page - Fedora_12_QA_Retrospective

AutoQA update

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

kparal updates

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

• Support for autoqa --local - https://fedorahosted.org/autoqa/ticket/52 - DONE
• Convert israwhidebroken to WSGI - https://fedorahosted.org/autoqa/ticket/91 - POST - awaiting review
• Use cases - https://fedoraproject.org/wiki/AutoQA_Use_Cases - INPROGRESS

Upcoming QA events

• NA