16:00:05 #startmeeting 16:00:22 #meetingtopic Fedora QA Meeting 16:00:33 #topic gathering bodies 16:00:52 I think we have a few folks out today ... adamw and f13 16:01:18 show of limbs for folks hanging out for the QA meeting today 16:01:31 * Southern_Gentlem 16:01:34 * Viking-Ice .. 16:01:40 Southern_Gentlem: Viking-Ice: greetings! 16:01:41 * skvidal is here 16:01:46 skvidal: howdy :) 16:02:32 * wwoods appears 16:03:06 wwoods: hey hey! 16:03:23 alright ... let's get started 16:03:47 I've got a proposed agenda out to the list, so if no objections, we'll just walk the agenda 16:04:12 agenda - https://www.redhat.com/archives/fedora-test-list/2009-June/msg00652.html 16:04:20 #topic Previous meeting follow-up 16:04:38 a short list of follow-up items from last week ... and I'm fail on the first item 16:04:42 * [jlaska] - update [[QA/Goals]] wiki document 16:04:44 :( 16:04:57 Still high up on my list ... just trying to figure out a good way to represent ideas and let it grow 16:05:28 I'm referencing the community architecture goals page as a starting point 16:05:36 jlaska: interpretive dance works well in the wiki 16:05:44 skvidal: no kidding! :) 16:06:08 so this will remain on my list for next week 16:06:41 we've got a lot of cool things going on ... and a some common themes to the work, I just want to wrap some wording around it 16:06:48 * jlaska struggling with that atm 16:07:10 okay, the only other item on the list is sort of vague ... but I know work has been happening there 16:07:14 * [wwoods] - updates on Rawhide acceptance test plan 16:08:39 did we lose wwoods? 16:09:01 sorry 16:09:08 oh good, no worries 16:09:17 so we have a test plan: https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan 16:09:31 it suggests 10 test cases for rawhide acceptance 16:09:48 we filled out 10 tickets in the autoqa trac to write those test cases 16:09:59 (see the link in the Test Cases section) 16:10:05 got some good feedback on the list for the plan 16:10:09 I've written one already: https://fedoraproject.org/wiki/QA:Comps_Validity_Test_Case 16:10:19 thanks to ldimaggi_ for pitching in! 16:10:38 yeah, the list of test cases etc. was determined after some discussion on fedora-test-list and on the wiki 16:11:26 wwoods: using the format you specified in the wiki text, I added my nick to the list of reviewers 16:11:28 anyone who wants to help write up (or review) the test cases.. we'd appreciate it 16:11:51 * jlaska encourages others who want to help review the test plan (or listed test cases) to do the same 16:13:21 wwoods: nice, any other updates on that front, anything to carry forward to next week? 16:13:28 Arent we forgetting in the "Basic Functionality" to check if an network connection can be established ? 16:14:34 hm. yeah, that's worth checking 16:14:39 no shit :) 16:14:42 as is seeing if yum can pull down packages 16:14:47 (which sort of implies network functionality) 16:14:48 exactly 16:15:01 the whole being able to update :) 16:15:19 okay, good call 16:15:47 I'm not quite comfortable yet on where to draw the line between acceptance testing of rawhide ... and more functional testing 16:16:09 the line in my mind is this 16:16:37 acceptance testing is 'do all the bits fit somewhere' is it POSSIBLE to install this given the depsolving requirements 16:16:43 AND 16:16:54 can a scripted installed actually succeed 16:17:06 if those two both test out correctly then, rawhide is acceptable 16:17:07 * jlaska lines that up with the comments in the introduction 16:17:09 beyond that is functional testing 16:17:42 Well, a scripted install as we typically run them 16:17:47 would require network and yum to work 16:17:54 since anaconda would be using those to fetch and install packages 16:17:56 right? 16:18:24 wwoods: I was wondering that as well 16:19:07 wwoods: well, it requires the LOADER network works 16:19:16 it doesn't require that the booted kernel network works 16:20:49 okay, so the take away is to add an additional network check on the post-installed system? 16:21:16 it's trivial to test, since typically our tests are going to report their status using the network 16:21:17 16:21:22 right 16:21:27 wwoods: fair enough 16:21:32 but there's thousands of different ways it can possibly fail 16:21:38 so it's not a very, uh, focused test 16:22:04 but then, irb.com is answering a very general question 16:22:27 international rugby board? 16:22:29 I dunno. I can go either way here. Technically we can perform installs without network 16:22:43 * skvidal must have missed something 16:22:53 #action add post-install network test to basic functionality in rawhide acceptance plan 16:22:56 but the vast majority of our tests (and testers) would be kinda busted if network or yum stopped working 16:23:06 skvidal: sorry - shorthand for israwhidebroken.com 16:23:22 oh right, sorry 16:23:32 I actually went to irb.com 16:23:48 curious how international rugby board and is rawhide broken have a lot of things in common, though 16:24:01 Being able to test yum functionality is the highest priority for the critical-path stuff 16:24:07 good point 16:24:17 so that proposal (and ensuing test plans/cases) will definitely cover that use case 16:24:52 stuff left off the Rawhide Acceptance Test Plan will *not* be ignored 16:25:07 but we won't even bother looking at the critical path tests until the acceptance test passes 16:25:21 agreed 16:25:37 kinda goes without saying.. 16:25:41 so the informal line is something like this: can someone actually test this thing. "Is Rawhide Broken?" 16:26:02 and I think most of us would consider it broken if networking was completely non-functional 16:26:09 or yum was unable to upgrade any packages 16:26:30 okay, we have a few topics to cover today ... any objections to moving on? 16:26:31 failures of *individual* network chipsets do not count as "broken" 16:26:33 nor wireless. 16:26:39 are there any other things we want to capture here? 16:26:41 agreed 16:26:51 in short: yeah, Viking-Ice is right - we need test cases for network and yum 16:27:05 very, very basic test cases 16:27:18 does it smell ... [yes] [no] 16:27:24 * poelcat wonders if any of the tests or open tasks could be queued up for working on at the FUDCon in Berlin this weekend? 16:27:27 so you can do both, actually 16:27:37 poelcat: we can talk about that shortly 16:27:38 at the same time 16:27:46 poelcat: I've got an update from f13 on that subject 16:27:54 skvidal: right - the implementation of the test cases will be pretty trivial 16:28:06 #topic Fedora 12 QA schedule changes 16:28:17 * poelcat just saw http://spevack.livejournal.com/84441.html 16:28:47 poelcat sent an updated F12 QA schedule to the mailing list last week 16:28:57 See https://www.redhat.com/archives/fedora-test-list/2009-June/msg00507.html 16:29:27 I wanted to talk about it briefly here to see what, if any, concerns the QA folks had about the schedule? 16:29:52 to hilight some changes that I keen on ... 16:30:17 A few of the informal activities that happened during F11 are now a bit more formal 16:30:28 like the scheduling of blocker bug days 16:30:49 and compose+hand_off of release candidate trees to QA 16:31:07 But poelcat has asked for additional guidance from the QA group 16:32:10 if I think back around F11, those 2 items listed above were items where it was unclear who was doing what when ... so I dig those changes 16:32:54 poelcat: are there any other areas of the schedule you're looking for feedback on? 16:33:17 * jlaska still on the fence with getting test days in the schedule 16:34:47 Viking-Ice: wwoods: do you folks have any concerns about the proposed changes? 16:35:03 or perhaps, looking for something extra? 16:36:00 * jlaska takes silence as violent agreement :) 16:36:13 * poelcat also wanted to volunteer to create an ical file for QA tasks if there is interest... something similar to http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng.ics 16:36:16 are there more frequent bug reviews in this schedule than in the F11 schedule? 16:36:39 * poelcat stepped away and is back 16:36:42 wwoods: yeah ... there are now 3 bug reviews ... 1 before freeze, and 2 following (prior to RC composes) 16:36:45 wwoods: yes 16:36:51 * Viking-Ice stands with jlaska on being on the fence with getting the test day's in the schedule.. 16:37:10 Viking-Ice: I'm there mostly since that schedule is *so* dynamic still :( 16:37:30 yeah, that was the only thing other than test-day scheduling that I wanted to be sure of 16:37:46 okay cool 16:37:56 * poelcat thinks wiki is probably best for the test days unless they will always happen on certain days 16:38:28 they always happen on Thursdays ... but that can change based on need 16:38:33 the other big distinction was two specific composes for a release and then subsequent testing 16:38:33 I dont really want to nailed the test days to down to a schedule we need the flexibility 16:38:36 or at least are planned for thursdays 16:38:48 Viking-Ice: okay 16:39:19 so next step would be to see if releng can accomodate composes on the days proposed 16:39:42 and maybe plan for them in advance? 16:40:42 sounds good to me ... that gives us some time to prep the test results reporting and any other QA call for actions 16:40:45 i was try to formalize some of the past discussion about limited QA capacity and not being able to test every compose 16:41:12 assuming rel-eng is okay with them, I think it's worth a try for the upcoming release 16:41:58 poelcat: okay ... any other points you wanted to raise? 16:42:09 that's it 16:42:49 oh, I forgot your iCal idea 16:43:36 I don't have any strong feelings on that yet 16:43:37 * Viking-Ice brb.. 16:44:00 * jlaska is used to going to the wiki 12/Schedule page 16:44:15 might be neat to try for this next cycle 16:44:24 but I can't say whether or not it's critical 16:45:09 if anyone else has input or thoughts on providing an ical schedule, please do follow-up with poelcat 16:45:15 #topic AutoQA - update from wwoods 16:45:43 wwoods: we may have tackled a fair bit already, but I have a spot in the agenda for an update on the autoqa project 16:46:00 well, the step after writing up a bunch of test cases is.. automating 'em 16:46:24 I think we've got some docs on setting up autotest 16:46:41 yeah I think I put the link in the ticket ... 'cause I knew I'd forget 16:46:42 ... 16:46:58 https://fedorahosted.org/autoqa/ticket/5 16:47:20 so Real Soon Now we'll be trying to write some test code and wikifying what we learn about writing tests for autotest 16:47:20 the KVM guys did most of the hard work already for us ... http://www.linux-kvm.org/page/KVM-Autotest/Server_Install 16:48:50 so I expect next meeting (or the one after that) we may have some test code and/or results to show 16:49:01 * Viking-Ice back 16:49:06 and a list of cases we need help writing 16:49:31 wwoods: when you say writing, do you mean automating or just defining wiki test cases? 16:49:48 sorry, automating 16:49:48 probably both :) 16:50:03 writing test cases in the wiki has already started and will be ongoing 16:50:13 hopefully finishing in the next week 16:50:35 automating those cases can start whenever we've got time to look at it 16:51:03 wwoods: f13 asked earlier today on #fedora-qa what things he could ask others to help with. I pointed to the list of test case tickets in autoqa trac 16:53:55 wwoods: would you like help from others on defining the test cases ... or is that a head down solo activity? 16:54:47 help from anyone who understands how we test this stuff already would be much appreciated 16:55:03 we're really just writing down all the unwritten requirements 16:55:30 would it make sense to send something out to the list asking for interested volunteers? 16:55:57 I mean, if we think this is an activity folks might be interested in contributing 16:56:02 once we have that written up properly, anyone with a little python skill could probably figure out the autotest API and write tests 16:56:10 sure, I'll do that 16:56:37 maybe we setup some time on irc for folks to gather and discuss/share ... dunno? 16:58:15 f13 also passed along a URL for a presentation he is giving @ FUDCon this week around autoQA (http://jkeating.fedorapeople.org/presentations/automatedqa.odp) 16:58:33 wwoods: any other updates on the autoQA front? 16:59:44 nothing I can think of offhand 16:59:48 okay 16:59:53 #topic Test Day SOP draft - update from awilliam 17:00:11 adamw is out today, but just a quick update on some documentation posted to the list for review 17:00:31 Adam's words do a better job explaining it than mine ... https://www.redhat.com/archives/fedora-test-list/2009-June/msg00662.html 17:00:43 summary: a draft SOP around hosting a Test Day 17:00:53 Any feedback or thoughts to the list are welcome! 17:01:38 okay ... last agenda item on the list ... 17:01:42 #topic Improve Bug Reporting proposal - update from viking_ice 17:01:59 https://fedoraproject.org/wiki/User:Johannbg/QA/Improve_reporting 17:02:06 Read that :) 17:02:15 You posted a link to a draft proposal last week. I wanted to give you a chance to let folks know where things are with the proposal 17:02:22 and what sort of feedback you were looking for 17:03:17 First status updates on QA task that I defined are on the draft 17:03:51 There are good news for reporters that have thought bugzilla reporting form is to complicated 17:05:15 when our bugzilla is upgraded to 3.4 ( which will happen not so long after it's release ) it will contain a simpler form by default ( user can click advanced to bring more elements into the reporting form ) 17:05:27 see --> http://lpsolit.wordpress.com/2009/05/24/simpler-form-to-file-bugs-in-bugzilla-3-4/ 17:06:19 oh cool 17:06:23 Ah very nice ... so does that solve the first item you've listed in the proposal? 17:06:35 yup 17:06:36 re: "Bugzilla reporting UI too complicated." 17:06:40 interestingly, it mentions http://hendrix.mozilla.org/ 17:06:46 which I hadn't heard of before 17:07:21 Now this is the big deal on the draft "Lack of needed information for maintainer(s) to be able to successfully work with the report." 17:09:04 Viking-Ice: you've got a lot of QA tasks listed in the proposal ... are these things you will be doing, or are looking for help on? 17:09:40 would not mind help 17:10:35 Perhaps abrt has gather all the needed info for us? 17:10:45 have you raised your ideas during bugZapper meetings? 17:10:56 nope 17:11:29 usually dont make appearance on bugzapper meeting 17:12:08 I ask because some of the areas of improvement line up with what the BugZappers team is trying to accomplish 17:12:20 perhaps a good way to team up? 17:12:27 Yeah sure 17:13:28 The main thing we need to solve is getting the info from maintainers on what to report store that in a db and reguire reporter to attache those files when reporting 17:13:54 does any one know how is abrt solving this issue ? 17:14:03 would it make sense for a more focused document on that topic? I know if working together during previous test days, this is a topic near & dear to ya 17:14:51 Viking-Ice: wwoods and I were discussing that yesterday. The project is active, but I'm not in the loop on their upcoming milestones 17:15:34 Ok 17:15:49 I'll try to digg up some info how they are addressing this issue 17:15:58 okay 17:16:17 IIRC they had (or were planning to have) plugins or conf files that specify what files to attach 17:16:23 now "Duplicated reports" already filed upstream improvements to the new simplified reporting form 17:16:24 there's some notes on the abrt wiki 17:16:32 (https://fedorahosted.org/abrt/wiki) 17:17:04 to atleast reduce somewhat the possibility on that 17:17:54 https://bug499320.bugzilla.mozilla.org/attachment.cgi?id=384113 17:18:18 Viking-Ice: were there any other items you wanted to address during the meeting today? 17:19:08 not really 17:19:33 anything you want to come back to for next weeks meeting? 17:19:48 Anyway 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 17:19:55 and store it etc.. 17:20:25 so both bugzilla and possible abtr can use it 17:20:34 I think that is something concrete enough that could generate good future discussion 17:21:21 If someone feels something lacking feel free to express it on that page 17:21:30 I've also started on https://fedoraproject.org/wiki/User:Johannbg/QA/Kernel 17:21:52 nice 17:21:56 with regards to j-rods wish on the F11RR meeting 17:22:05 seeing your second page makes it a little clearer what you're trying to do 17:22:15 I could see that growing rather nicely 17:23:11 These are just rough sketches ( both the improvements and the KTT ) 17:23:20 right 17:23:23 So I can keep track on things 17:23:47 for me ... like we've talked about before, just having a way to catalog content for testers to easily find would be a great start 17:24:37 anyhow ... let's open up for general discussion 17:24:42 #topic Open discussion 17:24:42 ok 17:25:02 we've gone way over today ... but I missed time for open-discussion last week 17:25:08 any topics/questions/concerns folks want to raise 17:25:50 * jlaska sets the fuse to 2 minutes 17:26:31 ... 30 seconds ... 17:26:33 this may come as a stupid question but who are the target audience with israwhidebroken.com and what is being hope to accomplish with that ? 17:26:53 Viking-Ice: ah ... not a stupid question 17:26:56 we testers ( atleast most of us ) know rawhide is more or less broken up to beta 17:27:29 yeah, I think we all know, but don't have concrete data readily available to prove it 17:27:30 I read the FAD report but failed to see the purpose of this 17:28:10 pulling from the 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. " 17:28:20 which servers who 17:28:35 serves 17:28:48 all of this leads up to providing a known good rawhide ... which serves QA for bug verification, feature testing, test days 17:29:13 and the release team, by providing a history on the health of rawhide as we approach milestones (or are past them) 17:29:32 Ah ok 17:29:39 for me ... it's all about consistently gathering data to facilitate decision making 17:30:21 yup.. 17:30:33 does that help answer your q? 17:30:40 indeed it does 17:30:43 cool! 17:31:02 alrighty ... unless any other thoughts, let's wrap it up 17:31:30 #endmeeting