15:01:18 <adamw> #startmeeting bugzappers 2010-06-15
15:01:18 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:26 <adamw> #meetingname bugzappers
15:01:26 <zodbot> The meeting name has been set to 'bugzappers'
15:02:27 * tk009 is here.
15:02:29 <adamw> #topic introduction
15:02:33 * jraber is present for BugZappers
15:02:41 <adamw> morning folks, sorry i didn't send out an agenda, i just dropped dead into bed last night
15:02:54 <adamw> was sorta hoping tk009 or rjune might do it but never mind =)
15:03:09 <tk009> I wasn't sure I'd be here
15:03:25 <adamw> ah k
15:04:23 <adamw> so mostly we just have some follow-ups from last week
15:04:40 <adamw> #topic last meeting follow up
15:05:00 <adamw> 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 <adamw> tcpip4000: so, did you get to that yet?
15:05:36 <tcpip4000> yes, I did some formatting to the paragraphs
15:06:00 <adamw> cool
15:06:09 <adamw> on the kernel page?
15:06:16 <tcpip4000> I want you to check them and give me some feedback
15:06:33 <adamw> ah, yes
15:06:36 <adamw> here's the diff:
15:06:36 <adamw> https://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=179284&oldid=177231
15:06:48 <adamw> 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 <adamw> #info tcpip4000 has revised the kernel triage stock responses - https://fedoraproject.org/w/index.php?title=KernelBugTriage&diff=179284&oldid=177231
15:07:22 <tcpip4000> ok, futhermore I added some warning about some information urls
15:08:21 <tcpip4000> the first item (Stick for prodding sleeping bugs with) I've mapped to Possibly fixed in CURRENTRELEASE
15:08:56 <adamw> #action tcip4000 to announce his kernel stock responses changes to mailing list for review
15:09:56 <tcpip4000> the second item  Installer bugs, have (or culd have) urls with outdated information
15:10:20 * mcepl is in
15:10:26 <adamw> yep, saw that
15:11:12 * Tech33_work is here, by the way
15:11:19 <adamw> hiya tech33
15:11:27 <tcpip4000> third item (  NEW state bugs ) is complex and depends of information from x org debugging or something else
15:13:49 <adamw> yup. well, our current plan is for graphics bugs to be re-assigned to the X driver package, of course.
15:15:05 <mcepl> 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 <adamw> mcepl: but the point is valid, that was just an example
15:15:43 <adamw> the required info will differ significantly depending on the subsection
15:16:27 <adamw> 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 <mcepl> adamw: sure, just want to emphasize my cup of soup (Czech saying)
15:18:21 <adamw> hehe
15:18:45 <adamw> 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 <adamw> sure, open floor
15:19:02 <adamw> so, next up...
15:19:07 * adamw jraber to look at setting up some bugzilla queries to do simple metrics
15:19:15 <adamw> jraber: you're up :) how'd you get on with this?
15:19:16 <tcpip4000> adamw: you are welcome
15:19:25 <jraber> 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 <jraber> 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 <jraber> I did a little modification to the bugzilla python program to give some BugZappers related stats.
15:20:44 <adamw> that sounds nice
15:20:58 <adamw> that web query is just what i was thinking of, too
15:21:12 <jraber> You output is here: (30days) http://fpaste.org/ohJs/ and Here (60-90days) http://fpaste.org/Honn/
15:21:15 <adamw> note that python-bugzilla is maintained within fedora/red hat so you shouldn't have any trouble having patches accepted
15:21:21 <jraber> s/you/the
15:21:35 <adamw> also looks great
15:22:21 <jraber> 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 <adamw> sure, even just what you've got so far looks like something we could use, though
15:23:12 <adamw> i'll put you in touch with the author and maintainer of python-bugzilla lately
15:23:14 <adamw> s/lately/later/
15:23:52 <jraber> 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 <adamw> looks like we can leave this with jraber for another week, everyone agree?
15:24:34 <jraber> +1
15:24:49 <tcpip4000> +1
15:25:19 <adamw> 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 <jraber> definitely.
15:26:02 <adamw> awesome
15:26:14 <jraber> I'll send some info out on the list this week, Looking for approval/criticism.
15:26:23 <mcepl> 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 <adamw> #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 <mcepl> otherwise, of course, +100
15:26:48 <adamw> yeah, i'll put you in touch with dkl too
15:27:13 <jraber> SQL would be MUCH better..
15:27:40 <adamw> #action adamw to put jraber in touch with wwoods and dkl
15:28:34 <mcepl> or maybe some of this is available over XML-RPC
15:28:34 <adamw> thanks for working on this!
15:29:11 <adamw> okay, final followup...
15:29:13 <jraber> 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 <adamw> 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 <mcepl> jraber: OK, whatever ... just remember we have cooperating (albeit sometimes a bit slowly ... this is not their highest priority) admins
15:30:34 <jraber> mcepl: thanks for the tip ;)
15:31:03 <mcepl> sure
15:33:20 <adamw> 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 <adamw> sooo, let's go on to...
15:34:06 <adamw> #topic open floor
15:34:09 <adamw> mcepl: you had something?
15:35:40 <mcepl> 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 <mcepl> 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 <mcepl> why?
15:36:43 <adamw> did you check their history? had they been set needinfo but then had the flag removed?
15:37:04 <adamw> #topic open floor - F11 EOL bugs not having needinfo set?
15:37:16 <mcepl> no, https://bugzilla.redhat.com/show_activity.cgi?id=473010
15:37:16 <adamw> poelcat: we may be needing you for this i guess
15:37:49 <mcepl> actually, this one was set to F12 (unfortunately, I would love it to die), but it has never had NEEDINFO set
15:37:57 <poelcat> adamw: sorry, what is the question?
15:38:15 <adamw> well, i don't think the 'EOL is coming!' message actually sets needinfo
15:38:30 <adamw> poelcat: see mcepl's line starting "yeah, I am going through gnome-desktop bugs" above
15:38:33 <mcepl> but it should, shouldn't it?
15:38:52 <adamw> not necessarily? it isn't actually requiring information, just providing notification of a process
15:39:05 <poelcat> we have never set soon-to-be-EOLd bugs go needinfo
15:39:11 <adamw> 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 <poelcat> it is simply a comment warning of the upcoming action
15:39:45 <poelcat> if it isn't a step on the housekeeping page we aren't doing it
15:40:18 <poelcat> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora13#Fedora_11_EOL_Warning--DONE
15:40:22 <mcepl> well, I would love to have needinfo there so that I know I don't need to deal with these bugs
15:40:44 <mcepl> or is it just yet another silly idea from me?
15:41:03 <adamw> i dunno, i can't quite feel it out =)
15:41:05 <adamw> wdyt poelcat?
15:41:11 <poelcat> hmm
15:41:18 <poelcat> i can see the value to mcepl
15:41:32 <poelcat> somethign feels strange though about setting 3,000 bugs to needinfo :)
15:42:08 <mcepl> how more strange it is than closing 3000 bugs ;)?
15:42:11 <poelcat> IOW does it really gain anything or just frustrate people
15:42:13 <poelcat> LOL
15:42:42 <poelcat> not as strange has having 60,000+ bugs that will never get fixed? ;-)
15:42:47 <mcepl> I don't think it frustrates them more than the message (and subsequent closing of the bugs)
15:42:48 <poelcat> like that other distro i've heard of
15:43:02 <mcepl> let's not go there
15:43:07 <mcepl> that isn't the point
15:43:13 <mcepl> I do agree with mass-closing
15:43:56 <jraber> Could we add a keyword to distinguish them without setting NEEDINFO?  EOL?
15:44:00 <poelcat> mcepl: for your purposes, couldn't you use the Triaged keyword to know which bugs you've looked at?
15:44:18 <adamw> we don't have it for these old bugs
15:44:24 <adamw> only the status, which is pretty ambiguous
15:44:33 <adamw> oh, wait, did we mass-add it to old bugs? i forget.
15:44:55 <mcepl> 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 <adamw> anyway, it's not reliable for old bugs, whether we auto-added it to ASSIGNED bugs or not.
15:45:11 <adamw> it's only going to be reliable from F13 onwards, when we've been explicitly setting it.
15:45:22 <adamw> we could put something in whiteboard maybe?
15:45:34 <mcepl> adamw: I think s/F13/F12/ but anyway
15:46:06 <mcepl> 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 <mcepl> which should happen
15:46:21 <adamw> that's what it's for, really
15:46:21 <adamw> and it's free text so it's easy
15:46:21 <adamw> just set the mass-add action to also put 'EOLSoon' or something in the whiteboard field
15:46:44 <mcepl> OK, whatever
15:46:48 <adamw> well, i guess for me it's just not strictly a needinfo case
15:47:01 <adamw> 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 <adamw> i wouldn't hate needinfo, just throwing the idea out there.
15:47:23 <adamw> anyway, thanks for bringing it up, maybe you and poelcat can come up with an idea for the next EOL round?
15:47:40 <mcepl> 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 <mcepl> 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 <jraber> 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 <adamw> i dunno, just pick something =)
15:54:36 <poelcat> 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 <mcepl> yes, I think so ... as a former lawyer I am anxious to have exact pleading in every note I send away :)
15:55:30 <poelcat> should it be set needinfo-reporter or needinfo-maintainer or ?
15:55:46 <jraber> needinfo-anyone.
15:56:20 <mcepl> most likely reporter
15:56:33 <poelcat> jraber: if it isn't specific, it looses its purpose
15:56:33 <mcepl> we would like to know he is alive and interested in the bug
15:56:57 <mcepl> certainly not maintainer, this is meant to save work for maintainers.
15:59:05 <mcepl> we are running out of time ... decide now or later?
15:59:34 <adamw> just pick something, i'm bored. =)
16:00:03 <mcepl> poelcat: please, next time set NEEDINFO(reporter)
16:00:04 <mcepl> thank you
16:00:06 <jraber> 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 <mcepl> jraber: that's the same ... if the care about email they care about needinfo ... nobody usually recognizes the difference
16:00:59 <mcepl> it is more for us, because it gets automatically cleared when the comment is made by reporter?
16:01:35 <jraber> Can a 3rd party clear the flag, if they are still experiencing the bug?
16:02:35 <mcepl> BugZapper yes, and we won't kill the bug based on needinfo flag (just on Product version)
16:03:00 <adamw> okay, that's fine
16:03:03 <poelcat> mcepl: okay, i'll add it to the procedure and we'll see what happens
16:03:19 <adamw> #agreed we'll go with needinfo(reporter) when adding the 'EOL coming soon' notification to F12 bugs
16:03:24 <adamw> thanks everyone...
16:03:26 <mcepl> thanks
16:03:29 <adamw> do we have any other open floor topics?
16:03:49 <poelcat> EOL for f11 runs on 2010-06-28
16:05:13 <adamw> okay
16:08:33 <adamw> let's close up =) thanks for coming folks
16:08:36 <adamw> #endmeeting