16:00:59 #startmeeting Fedora QA meeting 16:00:59 Meeting started Mon Jan 13 16:00:59 2014 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:03 #meetingname fedora-qa 16:01:03 The meeting name has been set to 'fedora-qa' 16:01:09 #topic Roll call 16:01:19 morning folks, who's around for a nice steaming does of qa meeting? 16:01:23 dose, even. 16:01:59 * kparal was just googling for 'does' meaning 16:02:10 it means the monkey needs to change keyboards again 16:02:29 jreznik's monkey is here to pretend he's here 16:03:22 * tflink is here 16:03:26 * mkrizek is here 16:04:06 * roshi is here 16:04:25 study finds coffee improves memory 16:04:43 * roshi has fresh coffee 16:04:52 * cmurf takes a sip, vaguely recalls he's human. Maybe. 16:06:09 * pschindl is here 16:06:18 cmurf: i guess i should go get some. hum. wonder why there's a dirty coffee cup next to me? can't quite remember. 16:07:27 cmurf: ah, I understand why my memory sucks - I don't drink coffee :) 16:08:03 * cmurf notices he's remembering all sorts of things with each sip. 16:08:12 9 inch powder day at Winter Park 16:08:18 adamw: you mean the one that looks like a whiskey bottle? 16:08:24 * pwhalen is here with coffee in hand 16:08:41 kparal: i deny everything 16:08:51 haha kparal 16:09:13 #topic Previous meeting follow-up 16:09:23 * roshi imagines a whiskey bottle with a homemade masking tape label reading "Coffee" 16:09:36 #info "adamw to send a mail to test@ about the ten year t-shirt thing" - clearly, that happened: https://lists.fedoraproject.org/pipermail/test/2014-January/120006.html 16:09:50 roshi: it says "Coffee. Definitely Coffee. Absolutely Not Something Else." 16:10:03 ha 16:10:21 adamw: that's a long label for a whiskey bottle 16:10:41 in the jack daniel's style 16:10:58 it wraps around, the more you drink the more the label tells you 16:12:26 hehe 16:12:39 so obviously we have a topic for the tshirt thing coming up, and we can move on 16:12:48 #topic EOL process handling 16:13:36 #info there has been a bit of a debate about the EOL (end-of-life) process, which is documented on the Wiki in a QA-ish space (Bugzappers), but which in practice has been handled by the program manager 16:14:05 so i thought it was probably wise to stick a topic on the agenda in case we want to change anything there 16:14:23 which ML was the debate on? 16:14:24 I still use Bugzappers area, it should be probably changed but for now it works 16:14:26 is there a reason we'd want to try and assert 'ownership' of the eol process, or are we ok with the program manager doing it? 16:14:35 * adamw looks for the thread 16:14:54 adamw: I can take care of it, of course with qa and fesco feedback 16:15:05 oh, yeah, it was in a non-obviously titled devel@ thread 16:15:35 I think EOL process is more program manager thing than QA thing. but I haven't read the thread yet 16:15:43 kparal: yep 16:15:58 #info thread started at https://lists.fedoraproject.org/pipermail/devel/2013-December/193094.html 16:15:59 but of course, I'm more than happy to get any feedback from qa and fesco 16:16:24 viking-ice's contention is that the process mainly 'affects' people who report bugs, and QA has an interest to ensure they don't feel rejected by it 16:16:33 (if i'm not mis-representing him) 16:17:18 my personal opinion is that i'm OK with the program manager doing it, as long as it follows a clear-cut policy we can provide feedback on if necessary (which afaik it does) 16:17:32 i thought it was an automated thing 16:17:49 cmurf: it's mostly automated thing, the question is mostly when and what 16:17:55 the comment added that also changes bug status at least looks automated 16:18:00 Viking-Ice: what would you do differently, in a nutshell? 16:18:24 i think that automated notice is fairly clear about why the bug is being closed 16:18:55 yeah, if there are some proposals to improve the message, let's do it, I don't see a problem 16:19:03 as a bug reporter well before I did anything within QA wasn't adversely affected by those messages; Fedora has a short life, sorta like a fairy, *shrug* it's the way it goes. 16:19:17 well, for f18, we are not going to do big change and with fedora.next we will probably need to revamp it 16:19:44 ahh that makes sense 16:19:50 cmurf: and it's always compromise between what we can fix and what can't be fixed 16:20:14 it's unfortunate to close so many bugs but also it's bad to pretend we will touch them 16:20:21 (or even fix0 16:20:31 well a lot of bug reports aren't that great 16:20:53 i like to think a scant minority of my bug reports are crap, but I know this is a non-zero value. 16:21:47 kparal, EOL belongs with us 16:22:06 seems like it belongs with a bot 16:22:26 you hit the date, the notices go out, the flags are switched - adios 16:22:34 is it the kind of thing we could update the message with a link to more wiki instructions, point them to a QA contact 16:22:48 then we can triage the experience from there? 16:22:56 can't we do that without owning the process? 16:23:01 that's what I thought it was cmurf 16:23:05 it has gone through several revisions in our community and it was handle by John originally since he was working on reviving the triage effort not because he was a program manager 16:23:59 roshi: I can do everything you propose with message - just F18 EOL is tomorrow, so I'm going to run my script after the last push 16:24:02 the fact fedora lives for 13 months isn't a QA thing at all, therefore i don't see how bugs having a related EOL becomes QA 16:24:07 kparal, in an nutshell what I would do differently would be to drop this EOL notice altogether and move existing bugs to new release 16:24:24 oh god no please no 16:24:35 Viking-Ice: moving bugs to the new release is part of that but AFTER review! 16:24:42 a LOT of bugs do actually get fixed 16:24:53 cmurf, do you relaize how many reports we have lost due to that bloody thing 16:24:54 whether they're firmware, package, upstream, or user error 16:25:16 Viking-Ice: I think that's a FESCo decision 16:25:16 Viking-Ice: But personally, I'd be against that as well 16:25:31 jsmith, this is not original fesco process is it 16:25:39 I also don't think QA can decide this on its own 16:25:47 kparal +1 16:25:52 Viking-Ice: yes I do because, i thank sweet jesus every cycle upon getting the 50+ emails telling me about my bugs being closed 16:25:52 kparal: I couldn't agree more 16:25:54 kparal, oh but they can decide this for us 16:25:54 https://fedoraproject.org/wiki/End_of_life_SOP does list it under Bugzappers, so we need to straighten that out whichever way it goes. 16:26:07 * adamw looking up the history of the process 16:26:09 Viking-Ice: as I said - it's compromise and better than pretend we will ever fix that bugs and believe me, I'm trying to take a look what I'm closing and sometimes it's sad what I have to close but as there are not enough people to fix bugs... 16:26:23 I was just going to ask for some more history adamw 16:26:51 I think it's better to be clear - sorry, we can't fix it instead of pretending we will fix it (and there's still that option to move that bug to newer version if reporter still have energy) 16:26:59 old bugs die, new bugs live. fair trade. 16:27:00 jreznik, compromize would be closing this as cant fix 16:27:02 not wontfix 16:27:14 because the maintainer could not fix it 16:27:17 that could be valid 16:27:23 can't vs won't 16:27:37 once it's EOL'd the fix wouldn't be pushed so that sounds like can't 16:27:49 Viking-Ice: To answer your question re: FESCo -- FESCo has the stewardship in Fedora over engineering decisions. Because this impacts more than just QA, I would say that absolutely yes -- FESCo has the right and power to decide this for us 16:28:11 Viking-Ice: it's can but won't but as I said, I'm more than happy to include any valid feedback, I'll note it for wed fesco 16:28:22 jsmith: yes although i can think of 4 better questions to ask FESCo than this, but okkk 16:29:09 jsmith, to answer your question this was handled by the triagers and had nothing to do with fesco if you still believe so point me to the original report in fesco tracks where it was discussed putting this on in the first place 16:29:32 adamw: for Bugzappers there - after it died, nobody did EOL for a while, but looking on house keeping, john/robyn/me do it forever 16:29:46 i'm more interested in when we decided to close bugs at eol 16:29:47 Viking-Ice: I always have the idea that you're living in a world with infinite resources, while we others don't 16:29:50 (and how) 16:30:39 adamw: it's definitely from john's era and well, it's the only thing to make bugzilla sane 16:30:44 isn't there a notice of EOL and then some time later another notice of it actually becoming EOL? 16:30:44 kparal, not that's WG madness ( infinity resources ) and what do you think I'm trying to do here preventing us from losing newbie reporters which this process has caused us 16:30:57 the bug report i mean 16:31:13 Viking-Ice: the problem is that the maintainers often don't reply, no that it is closed 16:31:24 yes 16:31:27 jreznik: http://translate.google.com/translate?hl=en&sl=de&u=http://www.linux-community.de/Internal/Nachrichten/Fedora-8-End-of-Life&prev=/search%3Fq%3Dfedora%2Bbugzilla%2Beol%26start%3D20%26sa%3DN%26hl%3Den%26biw%3D1080%26bih%3D1740 has a comment from michael schwendt suggesting it was new in f9 16:31:30 Viking-Ice: so what do you want to do? loose people - as hey, they never fixed my bug and they did not have balls to admit thay can't fix it 16:31:32 kparal, that's one of the problem the fact is people report and report until they get that EOL notice then they leave 16:31:33 maintainers don't reply, very common 16:31:42 they either already know of such bugs and just don't have time for bug management 16:32:07 so this EOL is to poke both reporters and maintainers and let them to react! 16:32:11 or they just don't acknowledge the bug 16:32:30 yeah i think it works fine, i'm unaware of a problem 16:32:39 cmurf, or they dont know how to fix it which is more common then you think ( packagers ) and they dont forward it upstream but we are talking about the EOL process here 16:33:07 i've yet to see users who report bugs with EOL get ants in their pants after the EOL notice. if it's still a bug they say "yoohoo, this is still a bug" and the flip it back to new/assigned or whatever 16:33:22 now maybe that could be made more clear in the EOL notice? how to flip the flag? 16:33:30 cmurf, and I have seen quite opposite for decates 16:33:41 guys, for F18 - reminder has been already sent, so I'm going to run my script this week and I'm more than ok to rework message based on QA/FESCO needs 16:33:51 http://johnpoelstra.com/five-months-of-bug-triage/ is interesting 16:34:12 suggests the policy of closing bugs came from the bugzappers initiative in the first place, as a cleanup drive 16:34:18 for fedora.next - a lot of stuff would be different, so we can work on improvements (and no, resetting version is not improvement at all ;-) 16:34:28 adamw: yes, it's cleanup 16:34:50 bug search finds these closed bugs right? 16:34:52 "Closing bugs that pertain to release no longer maintained" 16:34:58 a default search only searches open bugs. 16:34:59 or are closed bugs excluded from search by default? 16:35:00 it's done even in that super enterprise products people pays for bug fixes and even they have to do it :) 16:35:01 oops 16:35:06 well that could be a prblem then 16:35:12 maybe 16:35:12 Viking-Ice: and "Establishing a clear life cycle for the handling of bugs which includes rebasing rawhide bugs at GA and auto-closing bugs open for unmaintained releases " 16:35:40 adamw: that rawhide rebase is re-approved by fesco 16:35:40 so there's clearly some 'responsibility clean-up' to be done here at least 16:36:53 adamw: from that blog - "while also establishing better expectations with our users" this is what it is mostly for me 16:36:55 #info https://fedoraproject.org/wiki/End_of_life_SOP still shows the bug closure to be the responsibility of 'Bugzappers' 16:37:34 #info http://johnpoelstra.com/five-months-of-bug-triage/ implies the history of the EOL process - it was developed as part of the Bugzappers effort and originally done by poelcat with his Bugzappers hat on, not his Program Manager hat 16:37:36 * jreznik offers to work on the process with QA and FESCO feedback 16:38:21 otherwise scripts are open source, so anyone can run them :) 16:38:31 is the fesco ticket that was involved here still open? 16:38:48 adamw: it is 16:39:17 https://fedorahosted.org/fesco/ticket/1198 16:39:25 okay, so I guess we should post our response there 16:39:41 and scripts are available here https://git.fedorahosted.org/cgit/fedora-project-schedule.git/tree/scripts/closebugs 16:39:50 does anyone else support viking's proposal to change the EOL process to rebase all bugs from EOL release to a maintained release? 16:40:06 #info EOL scripts are available at https://git.fedorahosted.org/cgit/fedora-project-schedule.git/tree/scripts/closebugs 16:40:11 I don't 16:40:33 simple dumb scripts, we've got several complaints but with infra guys we decided not to rewrite them (at least not for now as these cases were limited) 16:40:37 no 16:40:54 i think we're throwing out baby arms with the bathwater, not whole babies 16:41:03 thanks for that image, cmurf 16:41:08 * cmurf snickers 16:41:37 It's an imperfect way of dealing with the problem, but a better way seems to require human intervention 16:41:46 adamw, I was not officially suggesting that 16:41:47 * jreznik is ok to handle that process to FESCO or QA or both but he is definitely against rebase without human review 16:41:50 does anyone think it's necessary/beneficial for QA to assert 'ownership' of the EOL process itself and take over running it from the program manager (whether we decide it should involve closing the bugs or re-basing them)? 16:42:04 Viking-Ice: sorry, i should've explained more clearly what i'm doing 16:42:13 i'm working to a proposal for what we should write in a fesco ticket 16:42:26 trying to pave the way for a consensus note 16:42:43 I think the process is fine with jreznik 16:42:55 I've yet to actually understand the problem, so I just keep hearing about solutions that I can't really agree with, *shrug* 16:42:57 that fesco ticket should be closed and we create a ticket for this in our tracker and take Matt suggestion under advicement 16:43:00 sorry I'm late 16:43:01 i was expecting we'd wind up in a place where the note is 'QA as a whole is fine with the program manager doing the EOL actions, so long as they're following an SOP and there's an avenue for feedback on it' 16:43:33 and viking can propose any changes to the process he thinks should happen on his own behalf, for fesco to discuss 16:43:55 Viking-Ice: matt's suggestion? and what would the ticket for QA look like? 16:44:32 regarding the program manager this should fall under the QA community member triager/ reporter merged thus being put back in the hands of the community under task we should be performing 16:45:07 how is that proposal going Viking-Ice? 16:45:56 I think QA being involved in attempting to help reporters keep relevant bugs alive is a good thing for the EOL process - and that can easily be done with a wiki page with up-to-date instructions 16:45:58 Viking-Ice: EOL is cross-functional process and always will be 16:46:15 we've been on this for 35 minutes, guys 16:46:36 that allows for Viking-Ice's merger proposal and QA involvement where it makes sense for EOL 16:46:36 and if you Volunteer to run that scripts two times per year, do it :) 16:46:38 jreznik, cross functional or not it still belongs with us and we reach out to -devel if when it becomes necessary 16:46:43 i'm not sure we're moving anywhere, and it looks a lot like viking has an opinion that no-one else entirely shares 16:46:58 * roshi will write up the wiki page if that's amenable to people 16:47:07 roshi: write up what wiki page? 16:47:51 jreznik, I used to have a track ticket containing stuff needed to be done at the beginning and end of each release cycle, then someone had a great idea within RH hired a QA community leader for the QA community which then deleted that ticket 16:47:55 updated page pointing people to a QA contact in the EOL message (suggested it a while back in the discussion) 16:48:14 ah, missed that. 16:48:23 this would be an edit to the EOL SOP page, then. 16:48:29 as I see it 16:48:33 er, rather, https://fedoraproject.org/wiki/BugZappers/HouseKeeping#End_of_Life_.28EOL.29 16:48:38 but I'm new to all this :) 16:49:22 adamw, no worries give it to FESCO and the program manager we invent another process to handle this with resurrection of the triage process 16:49:51 Viking-Ice: that's cool - I still use that HouseKeeping wiki 16:50:00 proposed #agreed We will update the FESCo ticket with a note that QA as a whole is not opposed to the current process, so long as we can contribute suggested improvements to the bug closing notices, etc 16:50:10 disagree 16:50:20 ack 16:50:32 ack 16:50:38 #info viking-ice's suggestions that QA should own the process and perhaps drop the closing of bugs on EOL releases is noted but not supported by a consensus 16:50:41 I'll respond myself since the so called RH cant keep this within the community 16:50:59 adamw, I did not officially propose that 16:51:09 I responded to kparal request what I would do 16:51:16 Viking-Ice: it is within community 16:51:21 hence 'suggestion' and 'perhaps', rather than 'proposal'. 16:51:25 what's not within the community? 16:51:39 jreznik, not within the QA community it's within FESCO 16:51:57 Viking-Ice: and what's FESCO? it's OT now :) 16:51:59 this belongs with us 16:52:39 i think you made your argument clear, viking-ice, it's just that afaict no-one *agrees* with it. so i'm trying to move on. 16:52:41 it's coordinated effort between QA and FESCO 16:53:08 I'm not saying we should not make the change suggested but the offical home for this process belongs to us if not I need an list from you yourself or fesco on what does so I can prepare proposal and changes in the QA community with that 16:53:29 * cmurf still doesn't understand the problem, other than his coffee cup is empty 16:53:46 cmurf: same here, just I'm going to have another cup of tea 16:53:57 Viking-Ice: i think it would be fine for your proposal to change the triage process to involve the EOL stuff if you like. 16:54:01 I wouldn't want QA to own this because I'm unwilling to say what person or personality in QA should then do that work 16:54:08 Viking-Ice: we can always come back to the topic as a part of that, no decision ever has to be a final one. 16:54:11 adamw, add a request from FESCO and the program manager what they think belongs in the QA community so we can just iron it out then and there 16:54:21 s/from/to 16:54:37 i don't think there's anything to gain by asking people to set out hard limits like that without a practical problem to solve 16:54:41 and we can adjust our community of what they think belongs there or not 16:54:55 and any proposal that follows 16:54:56 i think you should design your triage proposal however you think it ought to work best, and then everyone can discuss it from there 16:55:12 adamw, I cut out the bits like this 16:55:24 and rework it ( again) 16:55:48 guys, I have to run, my brother is awaiting me 16:55:54 it doesn't have to follow the precise contours of who's currently responsible for what - if it makes sense as part of your proposal to make EOL process owned by QA, and we like your proposal, then we can just do that 16:55:58 thanks jreznik 16:56:11 * cmurf waves 16:56:13 adamw, oh then you would be fine with it 16:56:14 bullshit 16:56:28 you either think it belongs with us now or you dont 16:56:28 umm 16:56:45 anyway I need to get some fresh air 16:57:00 Viking-Ice: not...really. right now the program manager is doing it and that's working fine, so i don't see any point of wasting time and energy to have someone else do it if it doesn't actually improve the process in any way 16:57:15 if there's actually some kind of concrete improvement to be gained from the change, that would be a different question 16:57:24 but so far you haven't been willing to suggest one 16:57:43 sounds like rearranging the loungey chairs at the local swimming pool 16:58:01 we've run for like 40 minutes and there still isn't a completely clear consensus on this, so i guess i'll just try to post a note to the ticket reflecting the discussion, and viking can add his own note\ 16:58:13 #info adamw will attempt to summarize the discussion for a fesco ticket note 16:58:18 #undo 16:58:18 Removing item from minutes: 16:58:41 #action adamw to summarize the discussion for a fesco ticket note on https://fedorahosted.org/fesco/ticket/1198 16:58:50 summarize it with stick figures... 16:58:54 we're kinda out of time for the t-shirt topic, but... 16:58:59 cmurf: being eaten by a t-rex? :) 16:59:05 ya 16:59:09 #topic 10 year anniversary t-shirt 16:59:24 so it seems some people got their t-shirts already, so i'm not sure we still have time to change the list, but i'll ask about that 16:59:34 did anyone have any major concerns about the current list or missing people or anything? 16:59:50 I want one, but I'm not sure I'm qualified (that's not the right word, but my vocabulary is limited due to lack of coffee) 17:01:20 does anyone involved in the project can have the t-shirt ? 17:01:26 RFE zodbot - 10 minute timer on #topics with a warning that says to the effect of "this topic has consumed 16% of the meeting time, is it really worth spending more? now?" 17:01:51 yachironi: I was asked for "So are we able to list QA people that contributed in a very laudable way along this ten years?" 17:02:16 cmurf: having seen the result of FESCo's similar procedure i don't think it'd help much. you just add a side argument about the timing. :) 17:02:32 yachironi: so...it was pretty open ended :/ 17:03:01 ok well maybe zodbot needs more attitude 17:03:14 and how could we judge that contribution ? 17:03:34 yachironi: there are lots of possible ways, i explained how i came up with the list so far in my post 17:04:14 welp, we're over time now, so we can continue discussing on the list, i guess 17:04:18 #topic open floor 17:04:22 anything really important for open floor? 17:04:50 f21 blockers? 17:04:56 * tflink is trying to find a channel for the qadevel meeting 17:05:06 danofsatx: what about 'em? 17:05:19 apparently nobody else got the message that fedocal is the master schedule, or I got a message that doesn't exist 17:05:27 tflink: i'll shut this down in a minute...if no-one yelled yet, means this channel's probably free till the next hour 17:05:46 yeah, but given what happened last week, I'm not sure 1 hour is enough 17:06:04 I was thinking about just using #fedora-blockerreview 17:06:28 sorry, had to take a phone call 17:07:00 ok, I was just wondering if we're following normal blocking procedures right now since we're nowhere near alpha 17:07:17 basically, yep, it's fine to propose blockers 17:07:22 we usually start reviewing them a week or so before tc1 17:07:55 #info it's fine to propose blockers for f21 already 17:07:57 ok. selinux is taking a beating so far, as well as nouveau 17:08:11 your selinux bug got closed as notabug, you might want to try a relabel. 17:08:45 OK, thanks for coming folks, qa-devel meeting is next.....somewhere 17:09:02 #endmeeting