16:02:09 #startmeeting 16:02:13 jlaska: no we are done and wouldn't want to degrade the quality of our next release :) 16:02:18 haha 16:02:25 rats, there goes my first excuse ;) 16:02:27 poelcat: don't worry, we can do that well enough on our own ;) 16:02:36 lol 16:02:39 #meetingtopic Fedora QA meeting 16:02:47 #topic Gathering warm bodies 16:02:56 lol 16:03:06 okay ... we've got a few familiar faces already ... let's do a roll call 16:03:08 * jlaska 16:03:18 * maxamillion 16:03:19 * poelcat stays in his seat, hi 16:03:23 * tk009 tk009 16:03:37 * wwoods cambot! gypsy! tom servo! and crooooooow! 16:04:05 * kparal1 is here 16:04:25 good job with the list then jlaska =) 16:04:39 * dpravec is here 16:04:44 uh oh ... the pressure is on ... good turn out today :) 16:05:32 okay, we've got a hard stop today in 55 minutes (Fedora Belux meeting) 16:05:43 let's do a quick recap from last week 16:05:48 #topic Previous meeting follow-up 16:06:15 * jlaska hopes Viking-Ice is lurking 16:06:20 https://fedoraproject.org/wiki/QA/Meetings/20090715#Previous_meeting_follow-up 16:06:36 * Viking-Ice jumps in a little late.. 16:06:42 Viking-Ice: sweet, welcome 16:06:50 [jlaska] - update fedora-qa privs so that viking_ice is on the default bcc 16:06:58 * f13 16:07:03 should be good there, Viking-Ice you should now be spamfull :) 16:07:09 f13: welcome! 16:07:35 Next up ... 16:07:39 * [jlaska] - file a bunch of tickets to track wiki RFC's (requests for content) for debugging pages ... email list seeking volunteers after 16:08:06 I filed just 3 so far for the 3 missing Debugging pages beland noted (see http://tinyurl.com/n6n24f) 16:08:19 i'm hoping to do some work on those 16:08:36 Will send out a mail to the list letting folks know it's a good way to get involved 16:09:10 adamw: thanks, there were some other pages beland noted could use improvement ... I haven't done anything with those yet 16:09:33 yeah, it's something i feel good about working on for sure, i have the resources and time for it again now 16:09:42 Awesome 16:09:46 * adamw went back from 8.9" to 40" of monitor space =) 16:09:50 i will need to feed my 12 months old daughter during this meeting. i would love to move it to another day of week, if that is possible... wednesday is not easy for me (my wife is going away for few hours, its 18:09 here) 16:10:09 dpravec: I've got a spot in the agenda to see if we can work up a new time 16:10:37 if i do not respond quickly, you know why :) 16:10:46 gotcha :) 16:10:49 okay, next up ... my always present Goal topic ... 16:10:57 adamw: total side note, you getting native res on that vaio p yet? 16:11:08 maxamillion: pm 16:11:24 * [jlaska] - update [[QA/Goals]] wiki document 16:11:50 Spent some time on that this morning, but need to keep thinking about a good way to represent and allow for growth 16:12:50 I'm not ready to toss it out for review yet ... but playing around with different methods in a draft page 16:12:55 https://fedoraproject.org/wiki/User:Jlaska/Draft 16:13:12 I'll keep playing throughout the week, if folks have input, feel free to get in touch with me 16:13:44 that's it from me 16:13:53 any other follow-up items folks wanted to discus from last week? 16:14:44 let me look at the agenda real quick again 16:15:17 well, we could talk about the changes to F12 schedule 16:15:42 Okay, I'll add that to the news section 16:15:59 #topic In the news - Fedora 12 QA schedule updates 16:16:26 as f13 points out, a group of us gathered in fedora talk this week to hash out some ideas around QA milestones on the F12 schedule 16:17:04 * jlaska trying to find linky 16:17:44 https://www.redhat.com/archives/fedora-test-list/2009-July/msg00241.html 16:18:11 poelcat: summarized the outcome ... as listed in the email above 16:18:26 he also updated the schedule pages on his people pages 16:18:42 http://poelstra.fedorapeople.org/schedules/f-12/f-12-quality-tasks.html 16:19:15 hrm, that seems not what you need. 16:19:39 oh, n/m. It shows the testing of things, just not when they're composed. 16:19:53 * poelcat hasn't done a recent review of the quality schedule... we discussed http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html 16:19:56 which overlaps w/ both 16:20:11 though it should be correct 16:20:30 the schedule looks pretty good to me 16:20:35 lots of bug review days which i like :) 16:20:57 the added bug days and agreement on the pre/post freeze composes is a huge plus for me :) 16:21:08 so speaking of ... this is a good tie into the next topic ... 16:21:16 #topic Alpha Blocker Bug Day #1 - Friday, July 17th 16:21:36 poelcat: sent out the reminder to f-test-list and f-devel-list ... https://www.redhat.com/archives/fedora-test-list/2009-July/msg00239.html 16:21:55 as you can see the list is completely empty right now ... which I don't think means we have no bugs 16:22:00 https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha 16:22:02 Bug 507676: medium, low, ---, notting, NEW, Fedora 12 Alpha tracker 16:22:38 maybe we should look at all f12blocker bugs and see if any are appropriate to block f12alpha too 16:22:46 i've honestly just been thinking about f12blocker and not f12alpha... 16:23:01 adamw: that's a good suggestion ... there was also talk about the F11target list which you already commented on I think 16:23:22 yeah, i don't have a massively strong opinion on that though. 16:23:37 agreed, nor do I 16:23:40 i can take a few minutes today to go through f12blocker and put appropriate stuff on f12alpha too if you like, put that down as an action item 16:23:55 https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1 16:24:06 not too too bad 16:24:37 so .. this raises the question for me, what type of issues constitute an Alpha blocker 16:24:42 should we go by severity? 16:24:49 semi-related... I drafted up https://fedoraproject.org/wiki/User:Poelstra/blocker_bug_meeting_sop 16:25:18 don't we have alpha release criteria we could go by? 16:25:58 I think https://bugzilla.redhat.com/show_bug.cgi?id=510033 should be a F12Alpha blocker 16:25:58 I just see the standard https://fedoraproject.org/wiki/QA/ReleaseCriteria page right now 16:25:59 Bug 510033: medium, low, ---, anaconda-maint-list, NEW, AttributeError: 'NoneType' object has no attribute 'name' 16:26:07 i think for alpha we should probably be going more or less by the critical path stuff 16:26:23 plus X, maybe? meh. 16:26:26 adamw: that's a good way to tie it into recent proposals 16:26:37 X is in the critical path. 16:26:38 X is in the critical path 16:26:40 oh ok. :) 16:26:43 wusses! 16:26:47 ;) 16:27:05 * adamw has visions of ancient beardy types shaking fists 16:28:12 Do folks have any opinions on documenting what we should be keeping on the radar for the alpha? 16:28:21 well, my suggestion is - make it the critical path stuff. 16:28:24 adamw: if there aren't many bugs to discuss on Friday... laying out the criteria would be a good thing to do 16:28:29 * poelcat won't be able to attend 16:28:48 adamw: yeah, I think limiting to the scope of components to critical path is a good thing 16:29:07 but does that mean all bugs against critical path components, just urgent, panics etc... 16:29:39 heck, I wonder if we should limit things to critical path for all milestones (and document how the criteria can be extended outside that scope) 16:29:54 i dunno, flying by the seat of my pants here. 16:30:05 welcome to the club ;) 16:30:40 I'd be willing to take a crack at documenting some guidelines, but I could use some help with that 16:31:35 i can think of some nice-in-theory approaches 16:31:48 we could just use the existing work and say 'critical severity bugs in in critical path packages'... 16:32:08 hmm, that's actually good and fits ... KISS 16:32:09 but in practical terms i'm not sure it can be that simple. i mean, i'm looking through f12blocker on the side right now 16:32:22 and we see 486284 , which is the grub support for ext4 stuff 16:32:42 which is a RFE right? 16:32:56 hmm, that's one way to square that circle, yeah 16:32:59 RFE's are different! 16:32:59 :) 16:33:02 heh 16:33:09 :) 16:33:16 well, we can try and go with a simple definition for now and get thornier from there =) 16:33:47 i would also see all apps having manpages... iirc in debian this is serious bug... 16:33:58 let me just jump in ... "all the bugs on the critical path" is too much IMHO ... there are tons of X bugs where Xorg just isn't. Are those alpha blockers as well? 16:34:00 love to see* 16:34:01 and if you say critical severity of critical path packages, then we'd have to spend the day defining the criteria to make those bugs critical severity 16:34:06 because I'm sure most of them aren't. 16:34:11 or many are that shouldn't be. 16:34:27 we have critera for the severity ratings already. 16:34:27 mcepl: "all bugs" is wrong. 16:34:31 f13: afaik ... severify is defined 16:34:38 defined yes, applied? 16:34:48 and does it truly match up with alpha release criteria? 16:35:08 exactly, that's I think what we're working through 16:35:11 probably not 100% yet, but that's fine. what we mean is "bugs that are critical if the criteria are properly applied"... 16:35:16 yeah, that's what i'm not sure about yet. 16:35:32 the grub thing was my first obvious non-conformer, but as jlaska points out that's an rfe, and those are always tricky 16:35:56 it's also tricky to do this pre-freeze ... but I think this is forcing us to ask these questions waaaay before we normally do 16:36:00 which is good 16:36:01 I kinda wish we had some brainstorm type thing that RFEs could go into 16:36:03 f13: OK, is this https://bugzilla.redhat.com/show_bug.cgi?id=498457 Alpha blocker (to the best of my knowledge it is still the same in Rawhide as in F11)? 16:36:04 to keep them out of bugzilla 16:36:04 Bug 498457: urgent, low, ---, airlied, ASSIGNED, "radeon" driver fails on F11 Preview and Xpress 200M 16:36:46 I'm new to the QA meetings so its highly possible this is common knowledge, but what's the process to get a bug added to a blocker list? 16:37:13 maxamillion: thanks for joining! 16:37:19 mcepl: i've been working for a while on the basis that bugs in a single specific piece of hardware are not 'critical', only 'high'...could probably codify that more explicitly in the severity policy 16:37:35 mcepl: because otherwise we'll just be drowning in critical X bugs 16:37:43 maxamillion: if you're confident that it's actually a blocker (see definitions) then you just add the bug alias (e.g. F12Blocker) to the "Blocks:" field on your bug 16:37:56 the alias for f12 alpha is 'F12Alpha' 16:37:59 adamw: yeah, that was exactly my point 16:38:00 jlaska: happy to be here :) ... mainly jumping in from the aspect of the Xfce SIG, that's my main focus at the moment but Fedora as a whole I'd love to help out as much as I am able 16:38:12 mcepl: lemme see what we have written down about that in the policy atm 16:38:19 * mcepl is pull himself out of the discussion again 16:38:22 adamw: nothing 16:38:26 IIRC 16:38:32 wwoods: are the blocker definitions in the wiki? 16:38:43 maxamillion: that's sort of the discussion now 16:38:47 jlaska: ah 16:38:51 * maxamillion misunderstood 16:38:55 adamw: just that there is no way how to make Xorg work for this card without quite particular changes in xorg.conf. 16:39:04 no worries, as I see it ... trying to figure out a good way to help contributors know what a good blocker candidate bug is 16:39:18 mcepl: yeah, so by the current quite short stanza in 'how to triage' it should be urgent, i agree; i'll add a caveat about hardware-specific issues there 16:39:25 maxamillion: current definition is, roughly, http://fedoraproject.org/wiki/QA/ReleaseCriteria 16:39:29 mcepl: in practice i've been calling bugs like that 'high', not 'urgent' 16:39:38 wwoods: thank you 16:40:07 okay ... let's summarize this topic ... 16:40:40 * the current release criteria are located at http://fedoraproject.org/wiki/QA/ReleaseCriteria 16:41:10 * For the Alpha, we've decided to evaluate bugs by severity:urgent and compoent in critial path packages? 16:41:22 or is that still a proposal that needs hashing through? 16:41:59 adamw: got a link to the severity definitions? I think my awesome bar still has the old draft link 16:42:06 mcepl: re that bug, this is where we start to apply "how many people does it hurt" thinking, as well as "how long until it can be fixed" 16:42:19 jlaska: there's two places: the How to Triage page - https://fedoraproject.org/wiki/BugZappers/How_to_Triage#Checklist_for_NEW_Bug_Triage (number 9) 16:42:36 that has the quick practical instructions 16:42:46 then the bug workflow page - https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow - has more detailed policy 16:42:54 https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity 16:43:04 the release criteria can (and should!) be updated to better match reality and new policies/proposals 16:43:15 they're not set in stone or anything 16:43:24 i have just added a quick exception to the how-to-triage page for hardware-specific issues 16:44:12 okay ... so we'll go with the notes above for now. And likely adjust as needed 16:44:36 if folks are interested in helping to define, feel free to drop me a line or send ideas to the mailing list 16:44:51 #topic Fedora 12 Test Day schedule 16:45:00 Just a quick blurb about F12 test days ... 16:45:04 the schedule is light at this point still 16:45:18 however, adamw and I have a few topics planned that haven't yet landed on the schedule 16:45:40 you may have to remind me about those, my brain is feeling lightly frazzled atm :) 16:45:49 ... incoming ... 16:46:01 I've got the full links in the minutes and on the discussion 16:46:10 but what's being planned so far includes: 16:46:12 * Revisit of X drivers (e.g. nouveau) 16:46:12 * Anaconda F12 features 16:46:12 o Storage cleanup [1] 16:46:12 o RAID [2] 16:46:14 o Partition UI cleanup [3] 16:46:16 * Upcoming NetworkManager changes 16:46:19 o IPV6 [4] 16:46:21 o System-wide connections [5] 16:46:24 o Mobile broadband updates [6] 16:46:27 * Audio test day 16:46:29 16:47:12 if folks have ideas or would like to pitch a test day topic ... let me or adamw know ... or send a suggestion to the team list (fedora-test-list) 16:47:43 Dracut and Virtualization are already planned 16:47:58 and thanks to Viking-Ice for his help in fleshing out test and debugging pages for dracut! 16:48:14 yeah that was awesome 16:48:25 https://fedoraproject.org/wiki/Dracut/Debugging 16:48:30 https://fedoraproject.org/wiki/Dracut/Testing 16:48:42 okay ... 12 minutes remaining ... 16:48:46 switching over to autoqa 16:48:48 #topic AutoQA - update from wwoods 16:49:06 wwoods: want to walk us through a brief update? 16:49:20 sure 16:49:55 So the first big milestone for autoqa is still the israwhidebroken.com project 16:50:10 the first big chunk of that was writing the rawhide acceptance test plan 16:50:14 * kparal2 has rejoined because of broken internet connection, sorry 16:50:20 that's https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan 16:50:42 last week I finished writing the test cases 16:50:49 kparal2: no worries, welcome back :) 16:51:06 two of the test cases required some critical path work to be done first 16:51:12 https://fedoraproject.org/wiki/QA:Core_package_dependency_closure_test_case 16:51:16 and https://fedoraproject.org/wiki/QA:Core_package_existence_test_case 16:51:48 those test cases will probably change as we develop some tools for examining the critical path packages 16:52:03 and then there's the two super-basic functional tests: https://fedoraproject.org/wiki/QA:Network_basic_test_case 16:52:07 and https://fedoraproject.org/wiki/QA:Yum_simple_update_test_case 16:52:33 as described in the test plan, those are the two functional things we'll check before bothering with any other testing 16:52:44 so don't get confused and think "this is all the testing they're doing?" 16:53:05 this is just the set of things we have to test before the *real* testing can even start. 16:53:32 so anyway - first versions of all the test cases are now complete and I'm starting to read up on autotest 16:53:44 and write automated tests for these test cases 16:53:48 using the autotest API 16:54:21 more info about the tasks / progress can be found here: https://fedorahosted.org/autoqa/milestone/israwhidebroken.com 16:54:40 * jlaska adds a blurb about cricital path to the test plan risks section 16:55:19 Could we please not use this blurp and rather use 
blurp
in the wiki when working with commands 16:55:34 that doesn't work inside bulleted lists. 16:55:38 wwoods: http://autotest.kernel.org <-- is this the autotest you are talking about? 16:55:42 or rather, it breaks numbered lists 16:55:43 maxamillion: yes 16:56:17 wwoods: cool, any other updates/concerns? 16:56:30 then let's not use it et al.. 16:56:48 I've asked kparal2 to look at the test case tickets you've outlined too ... so he'll be trying to familiarize himself soon 16:56:49 actually, for commands you should use {{command|foobar}} 16:56:50 maxamillion: yes, I've been working on getting it packaged and deployed in Fedora infrastrcuture for our use 16:56:58 oh, that's just for one-word commands though 16:57:00 adamw: that equally sucks... 16:57:03 sorry. 16:57:04 any other colors we'd like the bike shed? 16:57:04 f13: ah, awesome 16:57:07 jlaska: not really? things are going to get harder when we start trying to do the boot / installer / functional tests 16:57:09 or can we move on? 16:57:12 f13: puce! 16:57:27 but we'll deal with that once some of the other autotest stuff is worked out. 16:57:44 wwoods: yeah exactly 16:58:04 Viking-Ice: perhaps an offline discussion around updating the usage of in https://fedoraproject.org/wiki/Help:Editing ? 16:58:10 okay last topic ... 16:58:13 with 2 minutes left 16:58:24 #topic Updated meeting time 16:58:49 I'm sorry, but the meeting planner doesn't allow for more TZ's ... but here's what I'm looking at so far 16:58:52 http://timeanddate.com/worldclock/meetingtime.html?month=7&day=15&year=2009&p1=0&p2=256&p3=207&p4=204 16:59:14 was it bugzappers we did a matrix for before? 16:59:30 I'd like to adjust the meeting a bit to accomodate dpravec's schedule better ... besides it's been @ 16:00 for too long now :) 16:59:32 who do need these time changes 16:59:53 adamw: yes 17:00:01 ah, ok. so we don't have one for qa 17:00:06 jlaska: that would mean moving it earlier 17:00:08 tk009: do you have a link? 17:00:10 jlaska: we should probably do the same as we did for bugzappers 17:00:17 f13: another day or earlier 17:00:19 jlaska: I think at most I'd be comfortable one hour earlier 17:00:23 set up a matrix of possible times and see when works best for everyone 17:00:25 I dont sorry, not on my machine 17:00:34 yeah, we really can't have it more than one hour earlier for those on the west coast 17:00:43 one hour earlier is 7am for us in winter 17:00:51 adamw: rise and shine! 17:01:04 f13: does that fit the crappy daylight savings time or do we need to change it again later in the year? 17:01:11 ugh, that'd be a wakeup call 17:01:12 maybe it could be changed depending on summer time? 17:01:20 Viking-Ice: at present we're not changing for dst 17:01:27 we keep it UTC 17:01:36 Viking-Ice: as stated, an hour earlier puts it at 0700 during the winter here in the states 17:01:39 Viking-Ice: it's the same time in utc all year, which means for most people it moves one hour when dst hits 17:01:45 okay, so I'll take an action to work up a matrix on the wiki and ask folks for their input 17:01:51 the only other day I have an early meeting is every other Tuesday 17:02:04 jlaska: if you go through the test-list archives you can probably find a link to the matrix example page 17:02:05 so every other day either current time or less good one our earlier worksf or me 17:02:05 hopefully we can find a time that can highlight availability for folks 17:02:16 adamw: yeah I recall seeing it a long while ago ... thanks I'll take a look 17:02:27 jlaska: oh, found it: https://fedoraproject.org/wiki/Bugzappers_meeting_matrix 17:02:44 adamw: sweet, thx 17:03:00 okay I'll work this up and ask folks to update sometime after the meeting 17:03:16 #topic Open discussion 17:03:25 okay ... time for the word of the day 17:03:43 'Sassafras' 17:04:12 jk ... are there any topics/concerns folks want to raise during the meeting? 17:04:20 i just have a question - how many RHEL guys participate in the Fedora test days? just to have the notion 17:04:39 depends on the topic 17:04:43 how do you mean 'rhel guys' exactly? 17:05:09 well, internal redhat employees, working in RHEL 17:05:10 Rebrand rawhide spins I think nirik push this to legal or some where else we need to keep an eye for it 17:05:17 on it I mean 17:05:33 kparal2: varies hugely by topic...some test days are essentially only _for_ that kind of person, but for something like, oh, nouveau test day, probably none 17:05:35 kparal2: that's quite hard to measure 17:05:47 ok 17:06:00 Viking-Ice: oh thanks ... is there action needed by us on that topic, or is this something to keep on the radar? 17:06:03 Viking-Ice: what's our involvement in that? 17:06:03 kparal2: many "rhel guys" are Fedora users themselves, many are upstream developers who use Fedora as a deployment and test platform, and many use Fedora for next RHEL development 17:06:21 we make live cd for test day 17:06:26 do we need to rebrand them 17:06:34 oh interesting 17:06:40 ugh 17:06:47 exactly 17:07:01 okay, will definitely keep an eye on that and update the livecd creation page if needed (https://fedoraproject.org/wiki/QA/Test_Days/Live_Image) 17:07:08 Viking-Ice: thanks! 17:07:17 this is just plain stupid 17:07:48 Red Hat sues the Fedora QA group? :D 17:08:01 awesome 17:08:08 * adamw sees spot bearing down on him with legal papers 17:08:13 think xfce spin maxamillions case 17:08:18 rawhide spins that is 17:08:18 right 17:08:31 and all spins sigs for that matter 17:09:05 well, given that Red Hat/Fedora is the copyright holder on Fedora, we can make a case that we're allowed to do things with the copyright/logo that others aren't necessarily allowed to do 17:09:16 so things like snapshots and test day isos would fall under allowed 17:09:38 Any other topics/concerns to raise in the meeting today folks? 17:10:01 sorry, was side tracked by $dayjob 17:10:13 maxamillion: no worries 17:10:43 okay gang ... let's wrap it up for today 17:10:52 I'll follow-up later today with minutes 17:10:57 thanks everyone for your time :) 17:11:04 #endmeeting