15:04:47 <rjune_wrk> #startmeeting
15:04:58 <rjune_wrk> #chair adamw tk009
15:05:03 <rjune_wrk> #topic role call
15:05:09 <rjune_wrk> Who's here
15:05:14 <adamw> me
15:05:20 * arxs here
15:05:25 <rjune_wrk> I'll spell roll right next time.
15:05:26 * comphappy but I need to step out for the first 10 min
15:05:38 <rjune_wrk> comphappy: noted, thanks
15:05:41 * thomasj here
15:06:12 <adamw> any of our newer members around?
15:06:35 <adamw> just the cabal, then ;)
15:06:40 <rjune_wrk> We're going to push comphappy's update till he gets back. so it'll be near the end.
15:06:50 <rjune_wrk> #topic - Status on Critical path packages triage list
15:06:57 <rjune_wrk> arxs: you have the floor
15:07:15 <arxs> #link https://fedoraproject.org/wiki/User:Arxs/CPCL
15:07:37 <arxs> well, there is a new, shorter list, without the deps
15:08:11 <rjune_wrk> based on srpm names, right?
15:08:37 <arxs> i think, this and the old traige components list should cover enough work for triagers :)
15:09:03 <arxs> rjune_wrk: hope so :) i don't discover a way to grep the srpms automaticly
15:09:07 <adamw> without deps...well, i don't think we intended to dump the deps entirely, but practically speaking it might work
15:09:24 <adamw> we can only add as many components as we can reasonably expect to have people to cover, anyway
15:09:51 <arxs> adamw: i know, but i have start to slim down the old list with deps, but it's hard to make a choice for every package...
15:10:15 <adamw> right, as i said, practically speaking this is probably fine
15:11:38 <arxs> well, what the next step
15:12:06 <arxs> should i merge this into the [[BugZappers/Components_and_Triagers]] ?
15:12:24 <adamw> i say yes
15:12:33 <adamw> others?
15:12:55 <arxs> maybe we slip this decision?
15:13:03 <arxs> i mean we are 4 people around :=
15:13:20 <rjune_wrk> I would think so as well
15:13:55 <adamw> if you'd prefer that, sure, i guess
15:13:59 * adamw just wants to get stuff done :)
15:14:07 <rjune_wrk> I meant merge to bz page
15:14:11 <rjune_wrk> I'm with adam
15:14:27 <arxs> #action arxs merge the [[https://fedoraproject.org/wiki/User:Arxs/CPCL]] into [[BugZappers/Components_and_Triagers]]
15:14:35 <arxs> i will do so :)
15:14:45 <rjune_wrk> Anything else need added?
15:15:05 <arxs> not from me
15:15:49 <adamw> nope, seems good to me
15:15:54 <adamw> many thanks to arxs for managing this :)
15:16:00 <adamw> sorry we kept changing direction on ya, heh
15:16:17 <rjune_wrk> Nothing worse than changing requirements, often, in the middle
15:16:21 <rjune_wrk> moving on then.
15:16:23 <rjune_wrk> #topic - Status on Kernel bug triage
15:16:34 <arxs> adamw: you're welcome
15:16:50 <rjune_wrk> adamw: do we have a couple of bugs picked out to start with?
15:17:18 <adamw> i was waiting for a reply on whether you were OK with wireless or you preferred another component
15:17:45 <rjune_wrk> I'm ok with wireless
15:17:50 <rjune_wrk> sorry, didn't realize it was blocking on me
15:17:54 <adamw> ok then :) np np
15:18:27 <adamw> what i'd suggest next is what i suggest to new triagers - contact the maintainer, which for most wireless stuff is John Linville
15:18:33 <rjune_wrk> ok
15:18:40 <adamw> ask for any special info etc, just like with any other component
15:18:46 <rjune_wrk> there a particular bug required
15:18:48 <rjune_wrk> ?
15:18:51 <adamw> then pick some bugs and give it a shot...
15:18:55 <adamw> not really
15:19:04 * comphappy back
15:19:59 <comphappy> John Linville is really easy to work with, I did some development stuff with him a while ago
15:20:20 <arxs> #action rjune_wrk start triaging wireless kernel bugs
15:20:48 <rjune_wrk> that works
15:20:51 <adamw> rjune_wrk: i'll send a mail with the next steps too
15:20:55 <rjune_wrk> thanks.
15:20:56 <adamw> just so the mail thread is up to date
15:21:20 <adamw> there's actually rather fewer open kernel bugs than i'd imagined there would be...
15:21:41 <adamw> ah, they're all hiding in 11. :) 483 of the buggers
15:21:43 <comphappy> adamw: I think they tend to spike just after release
15:21:54 <comphappy> major spike
15:22:16 <rjune_wrk> ok.
15:22:24 <rjune_wrk> Anybody else have anything to add?
15:22:43 <adamw> nothing more from me
15:22:43 <arxs> only a thanks to rjune_wrk for doing this :)
15:22:47 <adamw> yep!
15:23:13 <adamw> this is the kind of thing our brave kernel triagers will be up against:
15:23:14 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=512683
15:23:15 <buggbot> Bug 512683: urgent, urgent, ---, kernel-maint, NEW, Internet not working
15:23:50 <adamw> :)
15:23:55 <rjune_wrk> LOL
15:23:57 <rjune_wrk> #topic - Triage Metrics and FAS - Update on the status
15:24:11 <adamw> and that's from an @redhat.com...good lord
15:24:14 <adamw> i apologize for the company :)
15:24:27 <arxs> it a duplicate from bug 504951 i guess
15:24:28 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=504951 high, low, ---, lpoetter, CLOSED DUPLICATE, ping does nslookup, nslookup works, wget fails with error in temporary name resolution.
15:24:32 <rjune_wrk> from some castro guy.
15:24:47 <adamw> arxs: yeah that was my guess too
15:24:50 <adamw> anyhoo
15:24:55 <adamw> comphappy, you have the floor!
15:24:59 <comphappy> ok so I thought my development copy was working, and it was not, i botched the relational database, I have someone helping me fix that
15:25:08 <rjune_wrk> ouch
15:25:10 <comphappy> so I went back to get what we had runing
15:25:20 <comphappy> it is working again
15:25:26 <adamw> yay
15:25:31 <comphappy> but I mad a late night type o
15:25:35 <adamw> ouch
15:25:47 <adamw> (this is like one of those good news/bad news bits on whose line is it anyway :>)
15:25:49 <comphappy> and it only did one day recording rather then 7 days even though it processed 7 days of bugs
15:26:06 <adamw> d'oh
15:26:19 <comphappy> I noticed an hour ago so it is only 600 of 3000
15:26:31 <comphappy> but in a few hours it will be uptodate
15:26:47 <adamw> question: say you get the development version fixed
15:26:57 <adamw> can that be put in place so that the history just rolls smoothly on?
15:27:04 <adamw> or is it going to have to start from scratch again?
15:27:10 <comphappy> adamw: I will regenerate it
15:27:11 <arxs> is the url still this http://publictest14.fedoraproject.org/triageweb/
15:27:22 <comphappy> we have new data that we want to capture
15:27:57 <comphappy> it would take longer to write a conversion script then to just recreate it
15:28:37 <comphappy> also once that is up, I really need to branch to tg2 there are major advantages for this kind of work in tg2
15:28:48 <comphappy> I have almost finished the required package reviews for that
15:28:59 <comphappy> (part of a DayJob project)
15:29:17 <comphappy> um any other questions
15:29:31 <adamw> what's tg2? :)
15:29:40 <arxs> turbo gears 2
15:29:46 <comphappy> I am still reading the bugs in trac, but they are in development version not the active one
15:29:59 <arxs> comphappy: the url, it is the still the same http://publictest14.fedoraproject.org/triageweb/ ?
15:30:05 <comphappy> arxs yes
15:30:15 <arxs> #link http://publictest14.fedoraproject.org/triageweb/
15:30:18 <comphappy> you may need to clear your cache if it looks the same
15:31:02 <adamw> OK
15:31:04 <comphappy> mostly I want tg2 for the tosca widget table, it will allow queries to be processed by it
15:31:21 <comphappy> as well as better flot support that renders the graphs that some have complained about
15:31:25 <adamw> the last question was about having more coders on the project - just to keep things smooth when you're busy, and obviously many hands make light work :)
15:31:43 <adamw> would the code be amenable to multiple devs? did you have anyone in mind?
15:32:00 <comphappy> yes, I have one other person who has been doing some advising, but I am up for anyone that wants to help
15:32:15 <adamw> great
15:32:24 <adamw> we can post a little call on test-list and python-list i guess
15:32:32 <comphappy> sorry I have really not been around the last month, I only have 3 more weeks at work and I have a major project to get done before I leave
15:33:03 <arxs> #action comphappy search for some pyhten dev to help out with the triage metrics project
15:33:08 <arxs> #undo
15:33:12 <adamw> i can do the searching actually :)
15:33:25 <arxs> #action comphappy search for some pyhton dev to help out with the triage metrics project
15:33:28 <adamw> of course comphappy can too, but i was planning to post to the lists
15:33:41 <adamw> comphappy: don't worry about it, we don't want this project to affect your work life!
15:36:48 <adamw> anything to add on that topic?
15:36:49 <arxs> anything more on this?
15:37:14 <rjune_wrk> guess not.
15:37:28 <rjune_wrk> #topic - Bugzilla Semantics - Discuss the proposals and feedback
15:39:03 <rjune_wrk> adamw: I think that's you
15:39:05 <adamw> just wanted to throw this back on the agenda to discuss developments
15:39:13 <arxs> at least, i ok with the introduction of the triage keyword, but don't change the old bugs
15:39:24 <arxs> start with this, if f12 is GA
15:39:30 <adamw> we had a couple of votes on the thread for my option 2 - start using the keyword going forwards, leave old bugs alone
15:39:33 <adamw> there's a third :)
15:39:40 <adamw> anyone against that option here? propose alternatives?
15:40:38 <comphappy> sorry about that my dorm assignment came in and I had to read that...
15:40:41 <comphappy> nothing to add
15:40:58 <arxs> can one chair please make a # agreed ? for option 2 ?
15:42:01 <adamw> well, just waiting if anyone wants to chime in
15:42:39 <adamw> guess not
15:42:58 <adamw> #agreed pursue adam's option 2 for the semantics debate on the list
15:43:01 <tk009> I type way to slow to say what I want to say on this subject
15:43:08 <rjune_wrk> LOL
15:43:14 <arxs> hi tk009
15:43:18 <tk009> =)
15:43:49 <tk009> call me a +1 in the eeting yet personally i have reservations
15:43:58 <adamw> tk009: we can wait, we've got 17 minutes and a clear schedule =)
15:44:15 <tk009> while this idea seems good
15:44:37 <tk009> we are making ourselves less relevant with this change
15:45:06 <tk009> devs would like us to do triage as long as it doesn't effect them in any way
15:45:20 <tk009> I don't see the worth in it
15:45:31 <tk009> take for example needinfo
15:45:43 <tk009> while f13 said its not a problem
15:45:59 <tk009> what he really said was in not the main problem
15:46:12 <tk009> how do we know it wont become one later
15:46:38 <tk009> I mean what we are doing doesn't qualify as triage
15:47:08 <tk009> that is my concern
15:47:14 <f13> I'd argue that it does qualify as triage, up to the point of setting bug status
15:47:18 <tk009> we are wasting our tie
15:47:34 <adamw> f13: well, the point of this proposal is we wouldn't be setting bug status any more :)
15:47:48 <adamw> needinfo's a flag, and this proposal replacing setting a status (ASSIGNED) with a keyword (Triaged)
15:48:10 <adamw> bugzappers don't typically make other changes, so we wouldn't regularly be setting status (except perhaps CLOSED for duplicate or incorrect reports)
15:48:21 <f13> sorry, I came in late, which particular proposal is being discussed this time?
15:48:23 <rjune_wrk> #chair f13
15:48:33 <adamw> f13: we're talking about the semantics proposal again
15:48:37 <f13> k
15:48:45 <adamw> tk009 is explaining his reservations
15:49:05 <f13> I think equating all of triage worthiness to the act of setting a bug status is a bit... dramatic.
15:49:08 <adamw> i don't think the question of whether what we do 'qualifies as triage', or whether we're technically setting status, is really that important
15:49:13 <tk009> I am being short with my words but I hope I am making sense
15:49:18 <adamw> but for the other bits, i can see tk009's reservations
15:49:39 <tk009> if I do a needinfo
15:50:04 <tk009> but as explained by anaconda team there is no one to work on it
15:50:08 <adamw> it is possible from the bugzappers perspective to read the objections from development groups as simply being 'we want to be able to completely ignore triage', i guess - i don't think that's what's happening but i could be wrong
15:50:16 <tk009> I have wasted my time and the reporters
15:50:17 <adamw> tk009: sorry, i don't get that bit
15:50:37 <tk009> they said we assign when there is no dev to work on the problem
15:50:46 <f13> by getting the required info while the reporter is fresh, that means that if/when anaconda can put somebody on the problem, the info is there, whether the reporter is or not
15:50:53 <adamw> you mean, if you do a needinfo and improve the quality of the report, but then find no-one's available to work on the bug once it's been improved to pass triage tests?
15:51:17 <f13> adamw: slightly wrong.
15:51:35 <adamw> tk009: I think they mean that we assign without determining which dev should be assigned to the bug, not that sometimes there isn't a dev available
15:51:55 <tk009> I took the later to be the case
15:51:58 <f13> I don't think they want to completely ignore triage, but particularly on the bugs that don't need any additional touching, no needinfo, correct component, etc...  they want the triage touch to be as light and unobtrusive as possible.
15:52:06 <tk009> but it could apply to any package
15:52:11 <f13> IE just set a flag somewhere so that the next triage person doesn't repeat the process.
15:52:33 <f13> when there is nothing to say, don't say anything.
15:52:49 <tk009> f13 I do understand that
15:52:53 <tk009> and can agree
15:53:09 <f13> most people I talk to see value in what triagers are trying to do.  Some of them haven't seen any successful triage efforts on any of their bugs yet, which is a bummer
15:53:10 <adamw> tk009: in that case, what i'd say is - i don't think the current proposal affects that at all
15:53:32 <f13> and some have completely opted out of triage to avoid the additional bug comments/status changes
15:53:34 <adamw> tk009: if it's the case that there's no-one available to work on a bug, then from that pov our effort is 'wasted' whether we set it to ASSIGNED or Triaged when we're done
15:53:43 <tk009> as I said I am +1 wit hpersonal reservations
15:53:55 <adamw> f13: fwiw, we focus efforts on a core group of components, due to restricted manpower
15:54:14 <adamw> f13: https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers is the list - if your component doesn't have a triager listed there, it's not getting much attention paid for triage
15:54:24 <f13> any effort that manages to drag needed information out of the reporter and into the bug is a successful effort, whether there is somebody there to immediately work on the bug or not.
15:54:38 <adamw> yes, i agree there
15:54:40 <f13> adamw: I mostly talk to "core" people.
15:54:42 <tk009> f13 I do not agree
15:54:50 <tk009> I have seen the reverse
15:55:07 <tk009> I have seen bugs closed that people put their time in
15:55:13 <tk009> no dev effort at all
15:55:27 <tk009> not that myself or the reporter is owed
15:55:30 <adamw> f13: well, if anyone who works on a component that's on that list isn't seeing useful triage happening, let me know and i'll take a look, see if the listed triager is inactive or something
15:55:41 <adamw> tk009: closed how?
15:55:47 <tk009> however when i see no movement I think they dont care what we are telling them
15:55:48 <f13> tk009: bugs closed by what?  The autocloser 2 releases later?
15:55:56 <tk009> yes auto close
15:56:03 <tk009> eaning no one did a thing
15:56:04 <f13> so lets look at a hospital example
15:56:06 <adamw> that's always going to happen
15:56:15 <f13> you walk into the hospital and you get triaged fairly quickly
15:56:16 <tk009> yes it will happen
15:56:20 <adamw> i've yet to meet a project which manages to address all its bugs
15:56:23 <rjune_wrk> adamw: I have to leave, can you take over?
15:56:25 <f13> just because your triaged doesn't mean there is a doctor waiting on hand to look at you
15:56:26 <tk009> it shouldnt be a regular thing
15:56:32 <adamw> rjune_wrk: sure, thanks for being here!
15:56:34 <f13> the doctor is busy looking at other people and may eventually get to you
15:56:36 <tk009> yes I agree f13
15:56:55 <adamw> tk009: in an ideal world, no - but there's nothing much we can do on the triage end to change that, that we're not already doing
15:57:02 <adamw> and i don't think this proposal affects that issue
15:57:08 <f13> yeah, that's the biggest thing I hear a lot of
15:57:25 <f13> we can do all we can to make the bugs reported look better and have all the right info, but we're still not helping to /fix/ the bugs
15:57:27 <adamw> tk009: since i've been on both ends of the process - even the simplest bug takes about, oh, an hour to address
15:57:35 <adamw> most take much longer than that
15:57:37 <f13> because there is still a limited pool of people who can do anything with the bugs
15:57:57 <tk009> I know its a manpower and time issue
15:58:04 <tk009> I dont mean to blame
15:58:05 <adamw> if you're working on a component which gets even, say, more than one report a day - it's very difficult to keep on top of all reports
15:59:16 <arxs> 2 minutes left
15:59:23 <adamw> ok
15:59:29 <tk009> well I am +1 and will support the proposal
15:59:31 <adamw> i think we discussed the topic well, anyway :)
15:59:37 <adamw> we're not taking immediate action now
15:59:44 <tk009> I a just not fully sure about what it will gain us
15:59:50 <adamw> so we can discuss at more leisure on the mailing list
16:00:02 <tk009> =)
16:00:08 <adamw> where tk009 has more time to type :)
16:00:18 <tk009> if I ever get damn free tie I will  post on that mail list thingy
16:00:23 <adamw> er, we have -18 seconds for open floor
16:00:38 <adamw> anyone have anything to bring up?
16:00:44 <tk009> thanks all for letting me rant =)
16:01:11 <adamw> oh, on the Announcements topic - there's an alpha blocker bug review meeting friday
16:01:32 <adamw> *please* do come along if you're interested and have the time...there's no special badge needed to get in, we like to have people there
16:01:37 <adamw> more heads generally gives good sanity checks :)
16:01:53 <adamw> and of course nominate any bugs you feel should be blocking alpha or final release: set them to block f12alpha or f12blocker
16:01:54 <arxs> i try my best to come
16:02:27 <adamw> putting a bug onto the list is the most sure way to have it reviewed, as we always go through the whole list
16:02:32 <adamw> and we really don't want to miss anything
16:02:42 <adamw> if we don't think it's critical we'll just drop it back down again, so don't hesitate to nominate bugs
16:03:12 <adamw> ok, any other business?
16:03:45 <arxs> nope
16:03:52 <f13> adamw: when will the keyword change go into effect?
16:03:58 <f13> and was it decided what to do with existing bugs?
16:04:22 <f13> once that change goes into effect, I'll see if I can get some folks who have opted out of triage to try it again.
16:04:26 <adamw> f13: as i said we're not taking a final decision here, we're not really a quorum - we just decided to continue the thread by pushing option
16:04:29 <adamw> option 2
16:04:45 <adamw> that's the one where we change to using the keyword going forwards, but leave existing bugs alone
16:04:48 <arxs> this mean we leave the old bugs as is
16:05:11 <f13> ok.
16:05:19 <adamw> so if there's no major objections on the list i'd imagine we'll take a final decision to go with that option at next week's meeting
16:05:26 <adamw> then we'd put it into practice going forward from there
16:06:05 <adamw> ok! we're over time
16:06:08 <adamw> thanks everyone for coming
16:06:25 <adamw> #endmeeting