15:06:08 <rjune> #startmeeting
15:06:08 <zodbot> Meeting started Tue Dec  1 15:06:08 2009 UTC.  The chair is rjune. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:13 <rjune> #topic Introductions
15:06:21 <adamw> yo
15:06:30 <rjune> Hello everyone, thanks for coming, who's here.
15:06:43 <Tech33> I'm here today
15:08:11 <adamw> mcepl: ping
15:08:29 <mcepl> oh, yes, pong
15:09:27 <adamw> rjune: i think that's the lot :)
15:10:08 <rjune> yup
15:10:10 <rjune> #Topic - HouseKeeping
15:10:26 <rjune> Updating the Components and Triagers List Link: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/FirstDayDevel
15:10:33 <rjune> tk009 wanted to discuss that
15:10:35 <adamw> tk009 had this one for action from last week
15:10:53 <rjune> ok, what's up?
15:11:04 <adamw> don't think there's much we can say/do without him, he was supposed to be reporting back on updating the component list
15:11:23 <adamw> updating the triagers list is something we all can do, just make sure you're listed in there under the appropriate component(s) :)
15:11:28 <rjune> ok
15:11:37 <rjune> #Topic - Anaconda triage
15:11:46 <rjune> - anaconda team is interested in having a permanent triager (alindebe is no longer around): ask for volunteers to work with denise
15:11:52 <adamw> alright, this is mine
15:11:53 <adamw> denise: ping?
15:12:05 <denise> hiys
15:12:07 <denise> hiya
15:12:08 <adamw> hi denise
15:12:18 <adamw> so, for anyone who doesn't know - denise herds the anaconda team
15:12:37 <denise> for severely limited values of "herd" ;-)
15:12:43 <adamw> :)
15:12:43 <pknirsch> :)
15:12:56 <adamw> up till recently, they've had a triager of their own, but that's no longer the case. right now she has the developers rotating to take a week of triage at a time
15:13:15 <adamw> but obviously it'd be better for everyone if we can get an anaconda triager again and free up the developers to...develop
15:13:37 <adamw> so really we're just looking for a zapper with a reasonable amount of time to work on anaconda triage
15:13:52 <denise> although a deeper knowledge of anaconda is VERY helpful in the triage and we'd love to help someone develop that
15:14:05 <rjune> define reasonable?
15:14:10 <adamw> right, also willing to learn :)
15:14:37 <denise> not afraid to get fingers into the code, understand tracebacks
15:14:40 <adamw> denise: i dunno, what do you reckon? just for the fedora side...
15:15:18 <denise> triager could hang out on anaconda channel, read sources, learn who works on what
15:15:28 <denise> because team does specialize
15:15:40 <denise> also we see a fair amount of dups
15:15:45 <adamw> hi juan
15:15:50 <denise> that do not necessarily look similar
15:15:55 <tcpip4000> hi adam, all, bit late
15:15:57 <rjune> denise, but how much time are you looking at per week?
15:15:57 <adamw> right.
15:16:18 <pjones> certainly not more than 50 or 60 hours ;)
15:16:22 <denise> 40+ hours, in my dreams ;-)
15:16:32 <denise> ah, Peter reads my mind again
15:16:55 <denise> seriously, its not going to happen without 20 hours or so to focus
15:17:01 <denise> as a WAG
15:17:02 <rjune> ok.
15:17:06 <rjune> WAG?
15:17:09 <rjune> nmind
15:17:15 <rjune> I'm slow today
15:17:21 <rjune> ok, what languages do you need?
15:17:27 <denise> python, C
15:17:50 <pjones> the former being much more important, usually.
15:18:00 <rjune> Anything else you can think of off the top of your head?
15:18:04 <adamw> note that we could also split it across several people, though it'd take a bit more co-ordination
15:18:06 <mcepl> well, realistically we won't get anybody with half-full-time job available, so we are talking about the team, right?
15:18:29 <adamw> mcepl: yeah, that's my thinking - no one person is likely to reliably volunteer more than an hour or two a day
15:18:55 <denise> which if all they want to do is the top-level scan requesting more information is OK
15:18:58 <rjune> yup, I just want to make sure I know what's up.
15:19:04 <denise> that still helps
15:19:11 <denise> but we clearly need deeper triage
15:19:30 <rjune> ok
15:19:34 <denise> which is why we've always resisted the traditional triager help
15:19:58 <denise> because anyone doing the top-level scan type of triage needs to know what not to touch
15:20:06 <adamw> the top-level scan isn't the only thing we do, we do follow up on info requests and so on in other components. but it's always a bit tricky to judge the time it will take
15:20:19 <denise> yes, absolutely
15:21:53 <adamw> well, there's not a big attendance at this meeting, especially not from the new members
15:21:53 <adamw> so i guess we should throw this to the mailing list
15:21:53 <adamw> but thanks a lot to denise for helping clarify the requirements
15:22:14 <rjune> that's why I was asking, I'll put out the email on it
15:22:22 <denise> thanks so much!
15:22:37 <rjune> I'll say we're looking for three to four people willing to do five to ten hours a week
15:22:42 <rjune> know Python, C
15:22:48 <adamw> we'll see if we can pull an anaconda expert willing to work for peanuts out of the bag =)
15:22:54 <rjune> willingness to get dirty
15:23:12 <rjune> sound about right denise ?
15:23:18 <denise> works for me
15:23:34 <rjune> adamw, anything to add from you?
15:23:59 <adamw> nope, that's it afaict
15:24:18 <adamw> oh, except to outline the Alternative Option
15:24:24 <rjune> the wha?
15:24:42 <adamw> if we can't find anyone / group of people to take over full in-depth triage we can co-ordinate with anaconda team for us to do partial triage
15:24:56 <adamw> which would basically be request for appropriate info and basic level of sanity / dupe detection
15:25:05 <rjune> ok.
15:25:08 <adamw> then hand it to anaconda team for more detailed work
15:25:24 <rjune> I won't even mention that. lets see what our posting gets.
15:25:33 <adamw> as denise says, in that case we have to know what _not_ to touch, which would basically mean 'don't assign bugs to any specific developer and don't set Triaged', i believe
15:25:39 <adamw> yeah, just to know that it's an option.
15:25:58 <rjune> ok.
15:26:03 <rjune> Moving on then
15:26:17 <rjune> #Topic - Triage metrics
15:26:28 <adamw> so yeah, this is another of mine :)
15:26:32 <rjune> - just a general 'where the hell's brennan', but also look at: https://bugzilla.redhat.com/browse.cgi
15:26:36 <adamw> for our new members - this is an ongoing story
15:27:03 <adamw> we've wanted for some time to have a tool for generating what we call 'triage metrics' - basically a record of triage-related statistics
15:27:52 <adamw> so we can look at things like how many (quantity and percentage) bugs are getting triaged over time, whether ones that get triaged get fixed more often, per-triager stats, stuff like that
15:27:52 <adamw> a group member called brennan ashton, irc nick comphappy, wrote us such a system, and it was good
15:28:07 <adamw> it was nearly done (for several months) and then he sort of stopped working on it and has shown up rarely since then
15:28:33 <adamw> last time he showed up he promised to provide some info on the code and also how he was generating bugzilla snapshots for it to work with, so we could give it to someone else, but...he hasn't done that
15:29:03 <adamw> the code for the existing tool is in triage git, for reference:
15:29:07 <rjune> has he shown up lately?
15:29:08 <adamw> #link https://fedorahosted.org/triage/browser
15:29:13 <adamw> (directory triageweb)
15:29:16 <adamw> not as far as I know, nope.
15:29:20 <adamw> anyone seen him?
15:30:21 <adamw> okay. he IS on the pre-registration list for FUDCon so if he actually goes i may be able to tie him down there and get him to work on stuff.
15:30:24 <rjune> Not I says the fly
15:30:44 <SMParrish_mobile> adamw: I will bring the rope
15:30:48 <rjune> I'll ignore the obvious joke.
15:30:49 <adamw> =)
15:30:57 <rjune> Where is FUDcon?
15:31:01 <adamw> Toronto
15:31:08 <adamw> http://fedoraproject.org/wiki/FUDCon:Toronto_2009
15:32:05 <adamw> alright so aside from that
15:32:18 <adamw> we can look at the Exciting New Thing
15:32:25 <adamw> jlaska pointed out https://bugzilla.redhat.com/browse.cgi to me
15:32:33 <adamw> at first glance it looks like the bug reporting interface, but don't be fooled!
15:32:49 <adamw> click through the product selection pages and you see glorious numbers and graphs and things
15:33:17 <rjune> #chair adamw
15:33:17 <zodbot> Current chairs: adamw rjune
15:33:22 <adamw> (in which you can see about 1/3rd of all bugs, roughly, have been triaged :>)
15:33:26 <rjune> adamw, can you wrap it up, I have a call
15:33:41 <adamw> so we could potentially use this thing for our triage metrics
15:34:09 <adamw> it obviously doesn't have enough info yet - nothing per-user, for instance - but it's being maintained and takes feature requests, so we could ask the maintainer to add the stuff we want
15:34:51 <adamw> really just a heads-up for now and to let people take a look at this thing
15:35:16 <adamw> if i can catch brennan at fudcon we might be in a better position to make a decision about moving forward
15:36:03 <adamw> anyone any thoughts, comments etc?
15:37:45 <adamw> well, i guess not
15:37:51 <adamw> so...that was that
15:38:04 <adamw> that's everything we had on the agenda list
15:38:05 <adamw> so
15:38:07 <adamw> #topic open floor
15:38:20 <adamw> open floor time - anyone have anything to bring up, ask about?
15:38:24 <adamw> don't be shy :)
15:38:39 <Tech33> I've got a question - xorg related, since that's where I've been spending my time
15:38:52 <adamw> sure
15:39:18 <Tech33> so, on 5 november, mcepl put a post out on basically every open bug that added a needinfo
15:39:32 <Tech33> 30 days later is 4 days from now
15:39:53 <mcepl> Tech33: s/every open/every open Xorg & Firefox/
15:40:07 <Tech33> what is standard procedure, do all bugs not responded to actually intend on being closed?
15:40:22 <Tech33> well, yes, I said it was xorg related, although i didn't relaize you also did ff
15:40:22 <mcepl> Tech33: we have to go through them
15:41:03 <adamw> but yeah, we probably will close all the ones which genuinely need additional information and which the reporter isn't responding to
15:41:08 <adamw> there's not a lot of point keeping them open
15:41:24 <Tech33> I ask this, because I have seen many ( more than a few) bugs where needinfo was put in, yet many months, and sometimes more than a year, has gone by
15:41:46 <Tech33> ok
15:41:55 <mcepl> Tech33: http://is.gd/5934P is your friend
15:42:02 <adamw> bugs aren't dead forever if they're closed
15:42:02 <adamw> the reporter can always re-open, and the close message will say that
15:42:20 <mcepl> Tech33: I am not very dilligent on going through this query
15:42:45 <Tech33> mcepl: heh, I've actually been using that query, as you've seen me posting on some of those lately with reminders
15:43:00 <tcpip4000> that "needinfo" flag is put in a regular basis on many bugs?
15:43:14 <mcepl> but try to give them a second chance whenever possible. Something like:
15:43:14 <mcepl> Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
15:43:14 <mcepl> is helpful. And once we have them in the NEEDINFO iron grip, the bug is not that costly to maintain.
15:43:25 <adamw> tcpip4000: needinfo is used all the time, yes
15:43:25 <Tech33> (I discovered the search page where I could ...acquire... searches by accident :)
15:43:29 <mcepl> tcpip4000: on every bug where you ask for information
15:43:48 <tcpip4000> but I mean, massively marking bugs?
15:43:56 <adamw> Tech33: yeah, stealing people's saved searches is great :)
15:44:05 <adamw> tcip: we didn't mass-mark bugs as needinfo, here
15:44:22 <adamw> tcpip4000: what happened is mcepl did a mass change on all bugs which were _already_ marked needinfo (in some components)
15:44:33 <adamw> basically he just sent them all an email saying 'please respond to the request for info'
15:44:40 <tcpip4000> ah, ok
15:44:50 <mcepl> tcpip4000: and then of course I set needinfo flag as well
15:45:11 <mcepl> adamw: no, that isn't this mass needinfoing
15:45:23 <mcepl> I sent it to all open bugs in particular components.
15:45:32 <adamw> oh, ok. sorry, got mixed up.
15:47:44 <Tech33> that was my only question/comment
15:48:04 <adamw> alrighty...anything else anyone wants to bring up?
15:48:16 <mcepl> for this topic or generally?
15:48:27 <adamw> either
15:48:29 <adamw> hi kimf
15:48:35 <kimf> Hey
15:48:42 <adamw> we're near the end of the meeting now :)
15:48:53 <mcepl> ok, I have one report and change in the GM script
15:49:17 <adamw> oh, did you make sure tech33 has the shiny version with the special X love?
15:50:06 <mcepl> didn't ... I will tell him to accquire it
15:50:13 <mcepl> (that's just JSON, Javascript is the same)
15:50:40 <Tech33> ooh, shiny is good
15:50:54 <mcepl> Tech33: later in #fedora-bugzappers
15:51:28 <adamw> so what's the report?
15:51:35 <mcepl> now, I have faithfully completed the task given me by this honorable collegium last week, and ALL open ASSIGNED bugs were marked with Triaged keyword.
15:52:59 <tcpip4000> mcepl: all fedora bugs or just rawhide?
15:53:07 <mcepl> especially non-Rawhide bugs
15:53:38 <tcpip4000> what for?
15:53:42 <mcepl> so since now on, following the last week consluion, we should mark ALL bugs just with Triaged keyword and forget about the existence of statuses
15:53:53 <mcepl> adamw: correct?
15:54:26 <adamw> um, not quite, i don't think
15:54:37 <adamw> we should still use ASSIGNED _as well_ for f11/f12 bugs
15:54:40 <adamw> as i wrote to the mailing list
15:54:55 <adamw> for f11/f12, set ASSIGNED *and* use the Triaged keyword...for f13/rawhide, just set the Triaged keyword
15:55:15 <adamw> that's the current status logically speaking anyway.
15:55:41 <Tech33> ugh
15:55:48 <mcepl> OK, so I wanted to report that GM script has been upgraded to work correctly ... err, not yet
15:56:05 <mcepl> we will have some git reset ;)
15:56:28 <adamw> Tech33: the nice thing is the gm script has a 'triaged' button
15:56:37 <adamw> Tech33: so once mcepl has fixed it up, you can just use that and not worry. =)
15:56:53 <adamw> it adds the standard 'this bug has been triaged' text as a comment and makes the appropriate changes to the bug
15:57:10 <adamw> so once he's adjusted it to work right, and you have the latest version of the script, you can just hit that button and it'll do the right thing.
15:57:34 <Tech33> ok
15:58:15 <adamw> alright, so...anything else? :)
15:58:30 <tcpip4000> and how this button know if you have the role to do that?
15:58:43 <adamw> tcpip4000: we only tell you where to find the script if you do :P
15:58:56 <adamw> tcpip4000: but don't worry, it doesn't cheat - if you don't have the bugzilla powers to make the changes, it won't work
16:00:07 <adamw> alright, so - ending meeting in 3...2...1...
16:00:25 <tcpip4000> adamw: ok
16:00:28 <Tech33> finished on time :)
16:00:38 <adamw> #endmeeting