QA/Meetings/20090624

= Attendees =


 * (Southern_Gentlemen)
 * Jóhann Guðmundsson (viking-ice)
 * Will Woods (wwoods)
 * Seth Vidal (skvidal)
 * James Laska (jlaska)
 * John Poelstra (poelcat)

= Agenda =

Proposed meeting agenda

Previous meeting follow-up
No traction over the last week. Still a high priority item for jlaska. Lot's great things happening in QA, and some common themes around them. Just looking for a concise way to document those efforts into a single page.
 * [jlaska] - update QA/Goals wiki document


 * [wwoods] - updates on Rawhide acceptance test plan

Test plan: https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan created. Some feedback on fedora-test-list helped shape the list of tests to include.

Viking_ice asked if we forgot to include a test for network connectivity as a basic functionality test?

Fedora 12 QA schedule changes
https://www.redhat.com/archives/fedora-test-list/2009-June/msg00507.html


 * wwoods asked if additional blocker bug days were listed
 * Viking_ice and jlaska both were on the fence with regards to whether or not to include test days in the formal Fedora schedule. Viking_ice suggested test days need more flexibility currently when it comes to the schedule.
 * poelcat hilighted the second change in the schedule around compose checkpoints during each milestone.

The next step will be to propose the schedule changes to rel-eng. If approved, we then work to plan around the changes.

AutoQA - update from wwoods
https://fedorahosted.org/autoqa

Wwoods provided an update on where the autoqa project is. Real Soon Now we'll be trying to write some test code and wikifying what we learn about writing tests for autotest. I expect next meeting (or the one after that) we may have some test code and/or results to show and a list of cases we need help writing.

Additionally, writing test cases in the wiki has already started and will be ongoing.

Wwoods intends to solicit volunteers to help with defining test cases, and once defined, automating the test cases. Anyone with a little python skill can likely contribute.

Test Day SOP draft - update from awilliam
Adamw was unable to make the meeting, but sent a quick update to the mailing list on a Fedora Test Day SOP document. Adam's draft email can be found https://www.redhat.com/archives/fedora-test-list/2009-June/msg00662.html. Please pass along any constructive feedback to the mailing list.

Improve Bug Reporting proposal - update from viking_ice
https://fedoraproject.org/wiki/User:Johannbg/QA/Improve_reporting

Viking_ice introduced several topics noted in the above document. All topics outline areas where improvements could be made around bug reporting.

Viking_ice provided good news for those concerned about the look'n'feel of the bugzilla reporting page. Bugzilla-3.4 intends to simplify this view (see http://lpsolit.wordpress.com/2009/05/24/simpler-form-to-file-bugs-in-bugzilla-3-4/).

Jlaska asked what specific feedback viking_ice was interesting in, and suggested possibly teaming up with the BugZappers since several of the proposed ideas line up with BugZapper goals.

Viking_ice commented, So to get one thing clear this is the problem that we are faced with ( taken from my improve_reporting page )
 * Lack of needed information for maintainer(s) to be able to successfully work with the report. - The reason for the lack of the needed information on a report is in most cases simply that the reporter has not a clue what to include in the report itself and is not mandatory to provide that information.The underlying problem is not the reporter nor the triager which often ask the reporter to include wrong information because the triager has no better clue what to include in the report so he ask for the most common include case ( usually to include /var/log/messages). The problem is that the maintainer(s) them self have failed to provide this information or has done so only to the reporter on a report bases.When a maintainer introduces a component into Fedora it should be mandatory for him to provide this information along with how to enable debug output and to provide test plans for the component.

Viking_ice asked if any one knew how abrt is solving this problem. Wwoods mentioned that IIRC they had (or were planning to have) plugins or conf files that specify what files to attach. Which does not solve the problem they just pass the burden to the maintainer to write that plugin or config file or us and since we need to have that info in other places like bugzilla then it's question if we should not gather that info from maintainers perhaps file a bug against all components in bugzilla and asking the maintainer for that info and we then we would write that plugin or config file or abrt would fetch the info for that in the same db as bugzilla would?

Viking_ice summarized by saying we need to come up with some plans on how to gather the info from maintainers on what they want on their reports on how to get that info from them. and pointed to User:Johannbg/QA/Kernel as an example based on j-rod's suggestion from the Fedora 11 retrospective meeting.

Jlaska suggested having a way to catalog content (e.g. debugging tips, or bug filing tips) for testers to easily find could be a great start.

Viking_ice notified the team he had started on User:Johannbg/QA/Kernel in regards to j-rods wish on the F-11 Release Retrospective meeting

Target Audience for israwhidebroken.com?
Viking_ice asked who are the target audience with israwhidebroken.com and what is being hope to accomplish with that? Adding that we, as testers, know that rawhide is largely broken before beta.

Jlaska suggested pulled content from the IRB.COM FAD proposal ... Provide a single, well-known location with information about whether or not Rawhide is broken, and a link to the last known-good Rawhide tree. Jlaska summarized, ''for me ... it's all about consistently gathering data to facilitate decision making.''

= Upcoming QA events =


 * 2009-06-30 - BugZappers/Triage_days
 * 2009-07-01 16:00 UTC - Next QA Meeting QA/Meetings/20090701

= Action items =


 * [viking_ice] - check-in with abrt
 * [wwoods] - add post-install network test to basic functionality in rawhide acceptance plan
 * [jlaska] - update QA/Goals wiki document

= IRC Transcript =

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