15:01:18 #startmeeting bugzappers 2010-06-15 15:01:18 Meeting started Tue Jun 15 15:01:18 2010 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:26 #meetingname bugzappers 15:01:26 The meeting name has been set to 'bugzappers' 15:02:27 * tk009 is here. 15:02:29 #topic introduction 15:02:33 * jraber is present for BugZappers 15:02:41 morning folks, sorry i didn't send out an agenda, i just dropped dead into bed last night 15:02:54 was sorta hoping tk009 or rjune might do it but never mind =) 15:03:09 I wasn't sure I'd be here 15:03:25 ah k 15:04:23 so mostly we just have some follow-ups from last week 15:04:40 #topic last meeting follow up 15:05:00 number 1: ACTION: tcpip4000 to synchronize kernel triage stock responses https://fedoraproject.org/wiki/KernelBugTriage and BugZappers stock responses https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses 15:05:09 tcpip4000: so, did you get to that yet? 15:05:36 yes, I did some formatting to the paragraphs 15:06:00 cool 15:06:09 on the kernel page? 15:06:16 I want you to check them and give me some feedback 15:06:33 ah, yes 15:06:36 here's the diff: 15:06:36 https://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=179284&oldid=177231 15:06:48 at a quick glance it looks nice...can you send an email to the mailing list asking people to review the changes? 15:07:01 #info tcpip4000 has revised the kernel triage stock responses - https://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=179284&oldid=177231 15:07:22 ok, futhermore I added some warning about some information urls 15:08:21 the first item (Stick for prodding sleeping bugs with) I've mapped to Possibly fixed in CURRENTRELEASE 15:08:56 #action tcip4000 to announce his kernel stock responses changes to mailing list for review 15:09:56 the second item Installer bugs, have (or culd have) urls with outdated information 15:10:20 * mcepl is in 15:10:26 yep, saw that 15:11:12 * Tech33_work is here, by the way 15:11:19 hiya tech33 15:11:27 third item ( NEW state bugs ) is complex and depends of information from x org debugging or something else 15:13:49 yup. well, our current plan is for graphics bugs to be re-assigned to the X driver package, of course. 15:15:05 tcpip4000: no it isn't (complex) ... don't think about it and file it to the appropriate Xorg driver (xorg-x11-drv-{intel,nouveau,ati} or xorg-x11 if in doubts. 15:15:33 mcepl: but the point is valid, that was just an example 15:15:43 the required info will differ significantly depending on the subsection 15:16:27 that's fine, though, we've always known that. we could develop more extensive stock responses as we go on, one for each subsystem maybe. 15:16:50 adamw: sure, just want to emphasize my cup of soup (Czech saying) 15:18:21 hehe 15:18:45 okay, anyway, looks like a good job by tcpip4000 so thanks a lot for that, and we can follow up more on the mailing list 15:18:49 * mcepl has a point about F11 EOS message for later 15:18:58 sure, open floor 15:19:02 so, next up... 15:19:07 * adamw jraber to look at setting up some bugzilla queries to do simple metrics 15:19:15 jraber: you're up :) how'd you get on with this? 15:19:16 adamw: you are welcome 15:19:25 Didn't have much time to dedicate to it, I forgot that I had a Family Reunion in the Ozarks to tend to. I worked up some (very) basic queries that give a high level view of the 'Triaging' activity 15:20:02 I owe an e-mail to the mailing list, but here is what little I have so far. https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=BugsTriaged-Last30Day&sharer_id=292687 15:20:34 I did a little modification to the bugzilla python program to give some BugZappers related stats. 15:20:44 that sounds nice 15:20:58 that web query is just what i was thinking of, too 15:21:12 You output is here: (30days) http://fpaste.org/ohJs/ and Here (60-90days) http://fpaste.org/Honn/ 15:21:15 note that python-bugzilla is maintained within fedora/red hat so you shouldn't have any trouble having patches accepted 15:21:21 s/you/the 15:21:35 also looks great 15:22:21 It needs more work, and I am slow (I am just learning python and bugzilla) but I think we can make it work well for us. 15:22:48 sure, even just what you've got so far looks like something we could use, though 15:23:12 i'll put you in touch with the author and maintainer of python-bugzilla lately 15:23:14 s/lately/later/ 15:23:52 Some things I'm not sure how to capture, most notably, how to tell who set the 'Triaged' flag. Looks like I may need to do some html parsing to get that out of bugzilla 15:24:25 looks like we can leave this with jraber for another week, everyone agree? 15:24:34 +1 15:24:49 +1 15:25:19 jraber: just don't start thinking about writing special dedicated apps for this, keep telling yourself 'simple' =) or at least, get some simple stuff we can use first, then move on to the complex ideas =) 15:25:50 definitely. 15:26:02 awesome 15:26:14 I'll send some info out on the list this week, Looking for approval/criticism. 15:26:23 jraber: it is possible to get into touch with bugzilla maintainers, so if you need some more data is probably better to get it from them via some SQL query, than via webscrapping. 15:26:27 #info jraber has worked up a web query and some initial python-bugzilla stuff already, will work further on this for next week and notify the list 15:26:40 otherwise, of course, +100 15:26:48 yeah, i'll put you in touch with dkl too 15:27:13 SQL would be MUCH better.. 15:27:40 #action adamw to put jraber in touch with wwoods and dkl 15:28:34 or maybe some of this is available over XML-RPC 15:28:34 thanks for working on this! 15:29:11 okay, final followup... 15:29:13 mcepl: so far what I am getting is via XML-RPC, but I don't think the History stuff is available. 15:29:23 * adamw adamw to get kernel team to provide a list of kernel subsystems 15:29:44 and of course, this being me, i didn't do it yet. =) d'oh. i will leave it on for this week, unless someone else wants to take it and make sure it gets done =) 15:30:01 jraber: OK, whatever ... just remember we have cooperating (albeit sometimes a bit slowly ... this is not their highest priority) admins 15:30:34 mcepl: thanks for the tip ;) 15:31:03 sure 15:33:20 that's pretty much all we have for follow-ups, i don't have any agenda items - tcpip4000 added his follow-up as an agenda item but we've covered that 15:34:03 sooo, let's go on to... 15:34:06 #topic open floor 15:34:09 mcepl: you had something? 15:35:40 yeah, I am going through gnome-desktop bugs (that's another poorly named component ... would you except from this name it is just completely silly small internal library? So, it is a bugs blackhole), but I hit on many soon-to-be-EOSed bugs (e.g., https://bugzilla.redhat.com/show_bug.cgi?id=473010). 15:36:12 and I got surprised than none of these bugs, which are almost dying are not set to NEEdINFO (despite the message which clearly asks for reaction) 15:36:14 why? 15:36:43 did you check their history? had they been set needinfo but then had the flag removed? 15:37:04 #topic open floor - F11 EOL bugs not having needinfo set? 15:37:16 no, https://bugzilla.redhat.com/show_activity.cgi?id=473010 15:37:16 poelcat: we may be needing you for this i guess 15:37:49 actually, this one was set to F12 (unfortunately, I would love it to die), but it has never had NEEDINFO set 15:37:57 adamw: sorry, what is the question? 15:38:15 well, i don't think the 'EOL is coming!' message actually sets needinfo 15:38:30 poelcat: see mcepl's line starting "yeah, I am going through gnome-desktop bugs" above 15:38:33 but it should, shouldn't it? 15:38:52 not necessarily? it isn't actually requiring information, just providing notification of a process 15:39:05 we have never set soon-to-be-EOLd bugs go needinfo 15:39:11 i can see it going either way...but i think right now it's not exactly an 'error' that it doesn't, we just never chose to do that 15:39:24 it is simply a comment warning of the upcoming action 15:39:45 if it isn't a step on the housekeeping page we aren't doing it 15:40:18 https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora13#Fedora_11_EOL_Warning--DONE 15:40:22 well, I would love to have needinfo there so that I know I don't need to deal with these bugs 15:40:44 or is it just yet another silly idea from me? 15:41:03 i dunno, i can't quite feel it out =) 15:41:05 wdyt poelcat? 15:41:11 hmm 15:41:18 i can see the value to mcepl 15:41:32 somethign feels strange though about setting 3,000 bugs to needinfo :) 15:42:08 how more strange it is than closing 3000 bugs ;)? 15:42:11 IOW does it really gain anything or just frustrate people 15:42:13 LOL 15:42:42 not as strange has having 60,000+ bugs that will never get fixed? ;-) 15:42:47 I don't think it frustrates them more than the message (and subsequent closing of the bugs) 15:42:48 like that other distro i've heard of 15:43:02 let's not go there 15:43:07 that isn't the point 15:43:13 I do agree with mass-closing 15:43:56 Could we add a keyword to distinguish them without setting NEEDINFO? EOL? 15:44:00 mcepl: for your purposes, couldn't you use the Triaged keyword to know which bugs you've looked at? 15:44:18 we don't have it for these old bugs 15:44:24 only the status, which is pretty ambiguous 15:44:33 oh, wait, did we mass-add it to old bugs? i forget. 15:44:55 well, yes I could, but it is even more lying than needinfo ... if the bug is actually alive, we may need to do proper triage, if we haven't done it already 15:44:57 anyway, it's not reliable for old bugs, whether we auto-added it to ASSIGNED bugs or not. 15:45:11 it's only going to be reliable from F13 onwards, when we've been explicitly setting it. 15:45:22 we could put something in whiteboard maybe? 15:45:34 adamw: I think s/F13/F12/ but anyway 15:46:06 why? needinfo just perfectly fits the bill here ... if reporter comments it gets cleared off automatically (even without BugZapper jumping on it) 15:46:13 which should happen 15:46:21 that's what it's for, really 15:46:21 and it's free text so it's easy 15:46:21 just set the mass-add action to also put 'EOLSoon' or something in the whiteboard field 15:46:44 OK, whatever 15:46:48 well, i guess for me it's just not strictly a needinfo case 15:47:01 we're not actively asking for some particular piece of info. well, maybe whether it still affects a later version, i guess. 15:47:08 i wouldn't hate needinfo, just throwing the idea out there. 15:47:23 anyway, thanks for bringing it up, maybe you and poelcat can come up with an idea for the next EOL round? 15:47:40 aren't we? Unless we get some info, the bug gets closed ... it looks to me like pretty interesting piece of information 15:48:37 I don't think it needs much discussion ... either we want it or we don't. We can postpone the decision to next time though 15:53:51 The more I look at it, the more NEEDINFO seems appropriate. We are asking both the maintainer and the reporter to update the bug (if necessary). +1 for setting NEEDINFO next EOL 15:53:53 i dunno, just pick something =) 15:54:36 if we go that route we should update the comment to be more specific about requesting feedback. right now it is more passive 15:55:17 yes, I think so ... as a former lawyer I am anxious to have exact pleading in every note I send away :) 15:55:30 should it be set needinfo-reporter or needinfo-maintainer or ? 15:55:46 needinfo-anyone. 15:56:20 most likely reporter 15:56:33 jraber: if it isn't specific, it looses its purpose 15:56:33 we would like to know he is alive and interested in the bug 15:56:57 certainly not maintainer, this is meant to save work for maintainers. 15:59:05 we are running out of time ... decide now or later? 15:59:34 just pick something, i'm bored. =) 16:00:03 poelcat: please, next time set NEEDINFO(reporter) 16:00:04 thank you 16:00:06 poelcat: I not certain I understand the purpose. I thought it was to serve as a flag for Triagers that the bug is idle, not necessarily to press the reporter to respond. The EOL reminder should be enough to motivate them, or the bug is unimportant 16:00:40 jraber: that's the same ... if the care about email they care about needinfo ... nobody usually recognizes the difference 16:00:59 it is more for us, because it gets automatically cleared when the comment is made by reporter? 16:01:35 Can a 3rd party clear the flag, if they are still experiencing the bug? 16:02:35 BugZapper yes, and we won't kill the bug based on needinfo flag (just on Product version) 16:03:00 okay, that's fine 16:03:03 mcepl: okay, i'll add it to the procedure and we'll see what happens 16:03:19 #agreed we'll go with needinfo(reporter) when adding the 'EOL coming soon' notification to F12 bugs 16:03:24 thanks everyone... 16:03:26 thanks 16:03:29 do we have any other open floor topics? 16:03:49 EOL for f11 runs on 2010-06-28 16:05:13 okay 16:08:33 let's close up =) thanks for coming folks 16:08:36 #endmeeting