15:00:14 #startmeeting fedora-qa 15:00:14 Meeting started Mon Jun 18 15:00:14 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:20 #meetingname fedora-qa 15:00:20 The meeting name has been set to 'fedora-qa' 15:00:22 #topic Roll call 15:00:35 * tflink is here 15:00:39 * Cerlyn is here 15:00:51 * akshayvyas is here 15:00:58 who be here for some swashbucklin'? 15:01:09 darn, wait. that's my pirate swordfighting meeting. ALWAYS getting those mixed up. 15:01:37 * kparal arrives 15:01:47 * jskladan hides in shadows 15:01:55 * mkrizek is here 15:02:38 mornin' folks 15:02:58 if anyone wants to join the pirate swordfighting meeting instead, just mail the cheque to... 15:03:09 I'll be here for about 25 minutes. 15:03:27 alrighty, let's get going 15:03:36 #topic Previous meeting follow-up 15:04:06 "adamw to review F17 retrospective and come up with an action plan" - i done that! well, quite a lot of it, and some we'll need to discuss today as a group 15:04:35 #info "adamw to review F17 retrospective and come up with an action plan" - this is mostly complete and some parts will be discussed today 15:04:54 "adamw to work with rbergeron to make sure housekeeping gets done for f16/f17/f18" - i mailed robyn and spot but didn't get replies yet. 15:05:13 #info "adamw to work with rbergeron to make sure housekeeping gets done for f16/f17/f18" - adam contacted robyn and spot, did not yet receive replies 15:05:34 "tflink to fix up blocker bug page for new bugzilla, probably as fedora-hosted static HTML rather than in MW" - tim? what's the status on this? 15:06:15 working on it - still hitting the occasional BZ proxy error but that's probably not a problem on my end 15:06:58 * pschindl is here (I was changing my laptop keyboard) 15:07:19 i think i've seen one of two of those in interactive use 15:07:22 so yeah, probably not you 15:07:23 anyone else? 15:07:52 the opinion in #fedora-admin is that it's due to load issues with bz 15:08:19 ok 15:08:47 #info "tflink to fix up blocker bug page for new bugzilla, probably as fedora-hosted static HTML rather than in MW" - work is in progress, hitting some 'proxy errors' from bugzilla but this is likely an error on the server end not in the script 15:09:01 "tflink to set up QA git account" - we know that's done 15:09:21 yep, done. I don't think there is much if anything in there but the repo does exist now :) 15:09:32 kparal's scripts 15:10:29 #info "tflink to set up QA git account" - this has been done, see https://fedorahosted.org/fedora-qa/browser/QA%20git 15:10:30 * j_dulaney waves 15:10:36 hi dulaney 15:10:52 How do we get access to said git account? 15:11:28 j_dulaney: the repo is public but if you want write access, ask adamw, kparal or I since we're the admins ATM 15:11:35 er, i don't see that off the top of my head. kparal? 15:11:54 tflink: That's what I meant 15:11:56 #link http://git.fedorahosted.org/git/?p=fedora-qa.git 15:12:32 ah, it's...oh, you beat me. 15:12:35 Normally write access is controlled for fedorahosted stuff by being in a group. 15:12:52 we still don't really have an active qa group in fas, but we could add one for git access i guess. 15:13:01 Hmm, reinstate the QA group? 15:13:12 yeah, seems like a reasonable use for it if it comes up. 15:13:16 https://admin.fedoraproject.org/accounts/group/view/gitfedora-qa 15:13:35 oh right, one is automatically created 15:13:38 Doesn't the group for access get created automatically (as part of the setup)? 15:13:43 yeah. 15:13:44 i forgot. 15:14:17 you can apply for commit access through the gitfedora-qa FAS group 15:14:22 https://admin.fedoraproject.org/accounts/group/view/gitfedora-qa 15:14:25 * j_dulaney just did 15:14:37 alrighty, so that's covered. 15:15:08 #info to get write access to git, apply to the gitfedora-qa group in FAS, and probably let adamw/tflink/kparal know why you need it. 15:15:30 #topic ARM as a primary arch 15:15:35 #chair j_dulaney tflink kparal 15:15:35 Current chairs: adamw j_dulaney kparal tflink 15:15:46 well, j_dulaney wanted this on the topic sheet, so here we go 15:15:51 is there anything specific to discuss? 15:16:03 Well, at SELF, the topic came up 15:16:25 Specifically, QA's role 15:16:31 And I brought up hardware 15:16:58 It would seem that there is some budget that could be made available for hardware for us to test on 15:17:01 i think we have quite a bit lying around at this point 15:17:06 hands up who has ARM 15:17:18 * adamw has an XO 1.75 sitting on his desk and a trimslice in a box 15:17:19 * tflink has a 1st gen panda board 15:17:27 * j_dulaney has nothing, although a raspberry pi is supposed to be coming 15:17:37 * Cerlyn has several XO-1.75s 15:17:43 kparal, anything over there? 15:18:07 no ARM in Brno afaik 15:18:12 I thought that most arm testing could be done with qemu 15:18:25 I'd like to order some Raspberry once it is available again 15:18:40 Anyway, my thought is that we should figure out what we don't have that is officially supported and make requests for that 15:19:02 tflink; the arm folks don't seem to like that 15:19:11 Fedora building cannot be done in qemu; I don't know if they plan to support qemu as a destination platform 15:19:36 pandaboard, trimslice, highbank, beagleboard, kirkwood and Pi seems to be the crop. 15:19:42 http://scotland.proximity.on.ca/arm-nightlies/ 15:21:06 so we're missing highbank, beagleboard, and kirkwood, apparently. i'm sure Pi will be covered, seeing how insanely popular it is. 15:21:23 kirkwood is all those *plug systems - sheevaplug, dreamplug etc. 15:21:30 Like I said, I'm *supposed* to be getting a Pi 15:21:58 yeah but it looks like most pi users are going to be using debian :-/ 15:22:07 Okay, I'll ping nb to see about getting at least one example of each of the above 15:22:32 doesn't mean that we can't run fedora on it, though :) 15:22:35 If we do get some hardware, how should it be distributed? 15:23:01 good question. i mean, whoever goes to the work of getting it can obviously have some. 15:23:51 i guess it'd be good for rh's brno office to have some too, though we can always do that through rh channels... 15:24:40 As far as actual testing, most of the current test criteria should work for arm 15:25:13 I guess if arm goes primary, would we slip the whole release if arm is blocking? 15:25:41 that's the idea, yeah. 15:25:49 I think that would be a real possibility 15:26:02 as always, it would depend on what the blocking issue is, I think 15:26:10 and yeah, we've pretty much established that we'd use a restricted version of the existing criteria to test ARM. basically the Base criteria, i think. 15:26:18 That was the other question that came up during SELF 15:26:54 I guess the only question is if the blocker is specific to one arm hardware version? 15:27:15 yeah, that could be a tricky situation. 15:27:19 j_dulaney, do we know where the hardware should go to? 15:27:33 j_dulaney, i will get with people to try to find budget somewhere 15:27:38 I thought that they were in that situation now where there were kernel issues on the panda's omap 15:27:51 and what is highbank? I'm not finding anything obvious in google 15:27:53 but to be honest, I haven't been following all that closely 15:28:05 nb: We'll figure that out once we know we can get some h/w 15:28:30 tflink: I think that is supposed to be fixed in 3.4 15:28:43 tflink: I think the issue was with the 3.3 kernel 15:28:51 But, I could be mistaken 15:29:20 nb: i didn't recognize that one either, the page just refers to it as highbank. 15:29:21 j_dulaney: yeah, that rings a bell but it was still an issue with blocker poential that was limited to specific HW within ARM 15:29:47 Indeed 15:29:58 And that's the kind of thing we're going to have to hash out 15:30:06 i guess we'd have to say that if Fedora ARM's approach is to claim to 'support' specific implementations, all of those have to be working, but nothing else does. 15:30:13 that'd be my call anyhow. 15:30:23 * j_dulaney is on the fence about it 15:30:41 My preference would be to block in such situations 15:30:56 #info supported ARM implementations are pandaboard, trimslice, highbank, beagleboard, kirkwood and Raspberry Pi; currently QA has a pandaboard and a trimslice, and some Pis on order. Also an XO 1.75, which is not listed 15:31:04 * tflink thinks that the first release with ARM as primary is going to be interested :) 15:31:11 interesting 15:31:13 #info j_dulaney and nb believe there is budget available to get more hardware 15:31:13 However, it seems like it would tick everyone else off if we held the whole release on just one arm h/w implimentation 15:31:36 sure, but we're experienced at ticking people off. =) 15:31:44 +1 15:31:50 hopefully we won't have so many late issues if we're testing more 15:32:08 #info question arises as to whether, with ARM as a primary arch, we hold an entire release due to one ARM implementation being broken 15:32:15 tflink: cos that works so well for x86 ;) 15:32:39 adamw: exactly, we never have major test escapes 15:33:52 i suspect if the situation arose we'd have to let lots of people get their oars in, anyhow, to establish some precedent. 15:33:52 adamw: i almost wonder if that should be a FESCo or even board question? 15:34:17 j_dulaney: right, it'd probably end up with lots of big guns at a blocker meeting. so i'm not sure if we can decide it in advance 15:34:39 we could say QA's position is to push for a high-quality approach, though, i.e. tend towards blocking, if that's what we believe. 15:34:57 adamw: It wouldn't hurt to advance it to FESCo 15:35:07 adamw: +1 on we would prefer to block 15:37:01 adamw: My thinking is that if we do advance it to FESCo, tell them our prefered outcome (we block), the rest of the project can't get mad at us 15:37:10 sure, that'd be a reasonable approach 15:37:45 If y'all want, I can file a ticket with FESCo 15:37:57 And we could all show up to that meeting 15:38:02 probably not worth it as of yet, at least until arm is actually taken as a primary arch 15:38:06 that hasn't happened yet afaik... 15:38:38 we need to move on from this as we have retrospective stuff to discuss, i think we raised the appropriate issues at least, anyone want to make any definite decisions or bring up other areas before we move on? 15:39:13 * j_dulaney is good 15:39:38 okey dokey 15:39:40 #topic Fedora 17 retrospective 15:40:09 so in working through the retrospective - https://fedoraproject.org/wiki/Fedora_17_QA_Retrospective - i found there were several things listed which set up more as questions for group discussion than simple 'action items' 15:40:24 so i wanted to run through those quickly 15:40:41 first one up: "RC schedule tinkering: should we aim for RC on Tuesday? What's the plan for Go/No-Go and Release Readiness meetings this cycle?" 15:40:48 darn, i should've asked rbergeron along. 15:40:56 rbergeron: ping, any chance you're here? 15:41:11 there's a chance 15:41:20 SMALL BUT THERE 15:41:28 are we retrospectiving now? :) 15:41:33 we are indeed 15:41:36 epic 15:41:39 * rbergeron takes a seat 15:41:54 * j_dulaney notes that rbergeron as a Beefy Miracle was epic 15:42:11 rbergeron: so do we have any definite plans for changing up the go/no-go and readiness meetings this cycle? 15:42:36 not yet. Feedback on how we thought it went having go/no-go on thursday this time instead of wednesday? 15:42:36 or should I try and kick start something? 15:42:51 worked fine for me. we got an extra day. did anyone complain about it? 15:42:54 (and final go/no-go has always been scheduled for tuesdays) 15:43:01 * nirik thinks thursday is fine and makes sense. 15:43:26 * j_dulaney liked Thursday 15:43:29 I think for Final - my only concern from the FPL/marketing seat is that I have all the people at Red Hat hot on my ass about wanting to schedule press releases and talk to pressy-interviewers 15:43:57 the other question is not just go/no-go _in relation to readiness_ but the absolute timing of them - do we actually need all that time between RR and release? do we have a specific list of everything that happens in that time and how long it takes? 15:43:57 But I think we gneerally start having a reasonable feel for it - and i haven't encountered anything where it wound up destroying their plansfor another press release for someone else. 15:44:49 hrmmmm 15:44:51 * rbergeron thinks 15:45:15 #agreed there is a consensus that we liked doing go/no-go on Thursdays and would like to schedule it that way for F18 15:45:28 adamw: I think that delay was for mirror propagation 15:45:49 that's one of the things often cited, yeah. i don't know if we know whether it really takes that long. 15:45:56 so WRT release readiness - I know that websites does quite a bit of work - I am not sure if there's an element there of not wanting to destroy people's weekends 15:46:22 Which makes sense 15:46:27 it takes less time than it used to these days, but yes, there's still time needed to sync out. 15:46:29 if we waited till, say, Friday - it's very late friday in some parts of the world - people may not be as responsive to email. (conversely, others may have more time available, but.) 15:46:43 For people to be getting the word that we're on (or that we're off). 15:48:04 OK. it sounds like the general tenor is that the readiness->release lag is reasonable. 15:48:56 so, on the other part of this question - for some reason we seem to schedule TC1s on tuesdays but RC1s on thursdays. 15:49:23 * j_dulaney reminds y'all that even the extra couple of days will wind up getting full up 15:49:25 that could entirely be an artifact of my idiocy. Have we noticed if one works better than another? :) 15:49:47 rbergeron: I think it's probably because the change deadline is tuesday and it's assumed we need some time from change deadline to rolling an RC, but that isn't necessarily the case 15:49:57 * j_dulaney thinks getting RCs out earlier = better 15:49:59 adamw: yeah 15:50:11 right, i was thinking something along the lines of simply saying that we roll the RC ASAP after change deadline' 15:50:26 not sure how we can express that in the schedule, but it seems like the logical approach 15:51:00 adamw: can you make a note of that in the meeting logs? 15:51:11 I wonder if that's what dennis is doing anyway - i feel like it is 15:51:31 well, we kinda schedule the RCs between us (qa and releng) 15:51:37 * rbergeron notes she would really really like to see a fixed time for what exactly the change deadline is also, FWIW, though that's not entirely this meeting's problem 15:51:43 but when we've rolled ahead of the date on the schedule people have brought it up 15:52:03 does everyone agree with the goal of rolling RC ASAP after change deadline? 15:52:36 * j_dulaney is +1 15:52:47 yes 15:53:12 adamw: bad/evil TCs won't affect that in any way? 15:53:14 yeah, that sounds good to me 15:53:20 yes 15:53:53 rbergeron: er, evil TCs? 15:53:54 ie; there's no threshhold of success to move from TC to RC 15:54:13 #agreed group agrees that we should aim to roll RCs as soon as possible after change deadline rather than schedule a specific day for them 15:54:30 rbergeron: the requirements for an RC roll are a) freeze in place b) no blocker bugs 15:54:41 the properties of the previous TC build do not in themselves matter at all 15:54:51 okay, just making sure :) 15:54:54 npnp 15:55:00 okay, moving along quickly as we're taking up time... 15:55:10 "Blocker bug meetings: should we move them from Fridays?" 15:55:32 I feel like we've done a lot of ad-hoc blocker meetings. 15:55:37 kparal says that current blocker timing is bad for Europe, especially RH people in the brno office, as it's right at the time they very much want to be going home for the weekend 15:55:44 rbergeron: this is about the regularly-scheduled ones. 15:56:00 home or pub 15:56:04 heh 15:56:05 yes, but I feel like we're always doing ad-hoc because we're tinking "shit, friday is 4 days away" 15:56:20 I pinged jlaska to ask, but i don't think he replied yet, if there's a specific reason we currently do the meetings on friday 15:56:22 do we get more bugs over weekends or during the week? 15:56:28 off the top of my head i can't think of one 15:56:34 rbergeron: I think we'd hit some of that no matter what day of the week we did it 15:56:44 rbergeron: i don't think there's a definite trend, it mostly depends on when the candidates are built and stuff. 15:56:50 rberegeron: I do most of my testing on weekend 15:56:53 if it's only once per week, we'll be having some ad-hoc meetings 15:56:57 So, probably a mix 15:57:07 tflink: +1 15:57:21 right, i think the ad hoc meetings are inevitable 15:57:24 Fridays are the best days for me 15:57:41 can anyone think of a schedule-related justification for any day in particular? 15:58:04 wednesdays make sense from a minor angle, if we're going to be always doing go/no-go on thursdays, it gives us a meeting ahead of the go/no-go to take stock 15:58:06 thursday to make it even throughout the week with the monday QA meetings? 15:58:06 Friday gives time after RC rolls 15:58:07 i think friday is good 15:58:28 or weekends 15:58:35 on second thought, I like adam's reasoning for wednesday more 15:59:21 +1 15:59:30 yes, but I think wednesday also assumes we'll be doing ad-hoc - we don't want to only wait till wednesday and have it be filled with new bugs that can't be addressed - particularly if people in europe are going home for hte day, and the go/no-go is the next day 15:59:36 akshayvyas: it'd be a lot of trouble persuading RH staff to show up on weekends, i can tell ya =) 15:59:54 adamw: agree 16:00:16 well then i say wednesday or friday 16:00:20 rbergeron: well, the idea is to kill one reason for the ad hoc meetings, actually - we always wind up doing one ahead of go/no-go during panic times, to knock a few stubborn blockers off the list 16:00:34 it sounds like we don't have a clear consensus here; discuss further on the list? 16:00:48 ^^ +1 16:00:52 kparal: would doing it earlier in the day on Friday work? 16:01:05 adamw: yeah, this'll probably be better on list 16:01:09 well, what's earlier? 16:01:26 I would think that doing it either earlier on Friday or Monday /tues would be good - i think that we'd maybe want more buffer to actually fix things if they're broken, but... :) 16:01:43 tflink: 13:00 gmt, you say? :) 16:01:45 kparal: same time as the QA meeting? 16:02:09 the current time is probably the earliest you can expect me to be fully functional. though of course the difference between 'essentially still asleep' and 'fully functional' is minute in my case. 16:02:24 #action adamw to start a list thread for further discussion of the blocker review meeting time topic 16:02:43 I don't think it's viable, it's Friday 5PM for us 16:02:51 blocker bug meetings make take several hours 16:03:13 OK, next thing on the list... 16:03:14 I don't say I can't attend from time to time. but we just lose people this way 16:03:16 May? 16:03:20 "How can we analyze the blocker bug lists for useful data? Bruno "I think it would be useful to review the blocker bugs to see if we can spot any trends. Just looking at the component counts might be useful. even if we don't do anything more." 16:03:42 so, this is one of bruno's ideas on the list which is interesting but pretty open-ended 16:03:50 i thought we could kick it around a bit to see if we can generate any specific action items 16:04:08 See trends from release to release so that we know what to test more? 16:04:09 brunowolff: is this something you were thinking of working on yourself? or just an idea you came up with in passing? 16:04:24 j_dulaney: I guess. the bit inside the quote marks is the exact text bruno put on the retrospective page. 16:04:24 something similar is on my list of stuff to look into if I have time 16:05:17 * tflink wanted to look into generating heat maps of bug urgency based on rate of bug change and sentiment analysis of comments 16:05:48 zoiks. 16:06:08 'sentiment analysis' sounds like something you could be making much more money doing for facebook =) 16:06:26 people already do it, AFAIK 16:06:31 tflink is using big words 16:06:43 well, if bruno's not around and no-one else has any specific bright ideas for this one, we can table it and i can ask on list 16:07:21 i'm not sure the straightforward component counts idea is terribly useful as i think we could all make a pretty good guess right here and now - 80% anaconda and most of the rest in the kernel, infrastructure like systemd/udev, or gnome 16:07:25 it's probably be good to bounce some ideas around 16:07:48 s/it's/it would/ 16:07:55 ok 16:08:07 adamw: it would be more interesting to look at timing and dependencies, I think 16:08:10 #action adamw to start a list thread about ways to analyze the corpus of blocker bugs 16:08:15 i can use fancy words too! 16:08:43 ok, so let's round up quickly 16:08:46 #topic AutoQA update 16:08:51 tflink/kparal, what's the news? 16:09:03 * adamw brb, call of nature - do summarize and move on to open floor without me if necessary 16:09:23 there is no update and won't be for a while I think 16:09:27 * tflink has nothing to report - have been working on other things 16:09:41 I wouldn't make this a persistent meeting item 16:09:41 that was quick :) 16:10:00 #topic Open Floor 16:10:07 so, what do you have? 16:12:57 * j_dulaney has https://lh4.googleusercontent.com/-1Nhl9RzDQfA/T99TV9i152I/AAAAAAAAA0g/jBA_Gzb5mjc/s800/GEDC0340.JPG 16:13:05 A Beefy Miracle 16:13:22 For ARM should we treat the different subarches like we treat x86 and x64? 16:13:27 http://4.bp.blogspot.com/_2u-weN31BFs/SJ8EEVM5sBI/AAAAAAAAAkc/87BYNgPz7BU/s400/hold-a-meeting.jpg 16:14:09 Cerlyn: Something like that 16:14:15 well i got one request,need mentor for proven tester :) 16:14:20 jskladan: Mine was better 16:14:45 proven testers are now suspended 16:14:51 indeed 16:15:37 Kparal: so no mentors that means i can't test for fedora :-( 16:15:45 j_dulaney: but mine was true... 16:15:52 you can test everything 16:16:10 akshayvyas: not sure I follow you, there isn't really a purpose for proventesters right now 16:16:11 we will help you, just ask on test list 16:16:20 akshayvyas: You don't need to be proven tester to file karma/bug reports 16:16:21 akshayvyas: you can still test just fine, it's just that being a proven tester doesn't change anything at present 16:16:46 akshayvyas: as long as you have a FAS account you can file feedback on updates, and you can still follow the proven tester instructions (they're good for all testers, really) 16:16:50 okay so you can test without joining anyyhing 16:16:56 anything 16:17:04 sure 16:17:47 got ya :) thanks... 16:18:06 * jskladan goes home *wink wink* see you around, gang 16:18:06 akshayvyas: you need a FAS account - https://admin.fedoraproject.org/accounts/ - for your karma to count, aside from that, you're good. 16:18:16 i didn't realize you lived in the pub =) 16:18:32 anything else for open floor? 16:18:38 jskladan: Peace, brohipnal 16:18:46 adamw: i got FAS 16:19:13 akshayvyas: then you're fine, just remember to log in before filing karma. 16:19:36 adamw: got ya thanks :) 16:20:15 alrighty, looks like we're set, thanks for coming folks 16:20:34 * adamw sets the Quantum Fuse for a couple of minutes 16:20:45 Quantum Fuse? 16:20:57 Related to Flux Capacitors by any chance? 16:21:16 it's the meeting fuse - you can never quite be sure exactly how long it is. 16:21:43 * kparal leaves 16:21:51 Ford Prefect probably knows 16:22:20 #endmeeting