From Fedora Project Wiki
mcepl_ hi 10:00
poelcat who is around/ 10:00
* jlaska 10:00
poelcat mcepl_: hi! 10:01
* j6k is around 10:01
* jds2001 10:01
poelcat welcome: jlaska j6k jds2001 10:01
jlaska Greetings! 10:02
* axelilly is a round 10:02
* j6k believes this is his first bugzapper meeting 10:02
jlaska mine as well :) 10:02
jds2001 welcome :) 10:02
j6k thanks 10:02
poelcat let's wait 60 seconds and then we'll start 10:02
mcepl_ how come there is 112 users in this channel -- do we have that many bugzappers? 10:03
* jds2001 has been consumed wiht $DAYJOB over the last week (and is likely to continue for awhile) 10:03
poelcat jds2001: we've got you covered :) 10:03
jds2001 mcepl_: lots of folks (including me) idle here 24/7 :) 10:03
jds2001 welcome stickster :) 10:04
* stickster here 10:04
stickster ...between phone calls to contractor. 10:04
poelcat alrighty 10:04
jds2001 ouch, still working on the kitchen? :/ 10:04
poelcat next week i will have matrix of tasks we are working on 10:05
poelcat this week I thought we could start by talking about how triage NEW rawhide bugs is going 10:05
jds2001 there aready is one woefully out of date :/ 10:05
poelcat looking at 10:05
stickster jds2001: It's the upstairs bathroom now. 10:05
poelcat we lost a tiny bit of ground 10:05
* jlaska clicks 10:05
poelcat in that I think last week we were at 1404 NEW and now closer to 1450 10:06
poelcat have folks had any issues/questions triaging those bugs? 10:06
poelcat the goal I proposed last week was trying to get that number much lower as the test releases approach 10:07
* poelcat starts singing "all by myself" and queues up "is anybody out there?" 10:07
jds2001 lol 10:08
jlaska :) 10:08
jds2001 10:08
mcepl_ all: I think we should stop all bug triaging efforts so that bugs won't get out of hand ... our efforts seem to make things only worse. 10:08
jds2001 132 filed last week 10:09
stickster poelcat: I tried to triage a few in the last week. 10:09
jlaska what if we add focus triage efforts specific to new features? 10:09
stickster poelcat: It was a trivially tiny effort on my part, but it made me more confident about doing some more this week. 10:09
jlaska s/add// 10:09
* poelcat isn't sure if mcepl_ is being sarcastic or serious 10:09
mcepl_ poelcat: very sarcastic, of course 10:09
jds2001 stickster: did you have any issues? 10:10
stickster jds2001: The first issue, which poelcat cleared up for me, was making it clear that my goal was only to get the bug out of NEW status. 10:10
stickster jds2001: I think that could be a little clearer on the wiki pages. 10:10
* stickster hasn't triaged before, so he could look at it fairly with completely fresh eyeballs. 10:11
poelcat 10:11
poelcat stickster: yes, the focus of NEW bugs is really just to make sure there is enough information present to work on it 10:12
poelcat and that it really should be there 10:12
mcepl_ I think we should write pretty clearly, that so far 90% of all work are NEW bugs and old NEEDINFO bugs. 10:12
mcepl_ stickster: and if possible you should try to reproduce it 10:12
* jds2001 saw a question on IRC while I was in a horizontal posistion about packages that we dont ship 10:12
* poelcat has been surprised how in 95% of the cases you don't need to be an expert in a component to triage it from NEW 10:13
jds2001 but they left before I could answer 10:13
stickster poelcat: Right, I believe you could state that as an actual objective -- "When you visit a bug, your goal is to move it out of NEW status to one of {ASSIGNED,NEEDINFO,DUPLICATE...}." 10:13
jlaska poelcat: that answers my question ... I was assuming that a lot of triage involved subject matter expertise ... but it sounds that's not the case 10:14
jlaska poelcat: I was going to suggest focusing traige efforts as part of the feature process ... but it sounds like that would be too restrictive 10:15
poelcat jlaska: no, not at all... i've found I can triage 20 or 30 bugs in 30 minutes 10:15
jlaska wow ... nm :) 10:15
ecntr1 <eof> 10:16
poelcat stickster: being newly exposed to this process... do you see any ways the docs and getting started stuff could be clearer 10:16
rsc hm, the bugtriaging-foo mostly annoys me. It marks much of my bug reports somehow even if the maintainer is just too slow and lazy to look at it (sometimes I've already attached a patch for fixing the issue etc.) 10:16
poelcat some way to better convey what can be done 10:16
poelcat rsc: hi, could we cover your concerns in a little bit? 10:17
rsc poelcat: of course 10:17
poelcat mcepl_: based on your experiences doing a lot of desktop triage how far do you think we can realistically get with NEW rawhide bugs by the beta? 10:19
poelcat approx 1 month from now 10:20
poelcat j6k: have you had any good/bad experiences triaging bugs so far? 10:20
mcepl_ I don't know -- it very much depends on how much we expect from bug triager to do -- when I am really busy and really sloppy I can make like 50 bugs a day, but that's full-time job. 10:21
* stickster returns -- sorry, had to get back on the phone. 10:22
j6k poelcat: had a phone-call, back now 10:23
stickster poelcat: The best way to document something, I find, is to be absolutely clear what you assume people know. 10:23
j6k i started by looking for duplicates in NEW issues and that worked quite well 10:23
mcepl_ poelcat: on the other hand, when I dive into some Firefox bugs, I can easily spend couple of hours on it. 10:23
stickster poelcat: Without that assessment, you can't know how much you need to explain. 10:24
poelcat stickster: so we could improve this page BugZappers/TakingAction 10:24
mcepl_ BTW, to show my former lawyer's nature -- 10:24
mcepl_ (this is the list of my Rawhide NEW bugs) 10:24
* stickster suggests also pulling example bugs to show how a triage *has successfully moved* a bug from NEW to each other status that's applicable. 10:26
poelcat okay so before we move on... does everyone continue to agree that NEW rawhide bugs is our first focus and goal? 10:26
mcepl_ I think so 10:26
jlaska poelcat: yeah 10:27
* j6k agrees 10:27
jds2001 yeah 10:27
mcepl_ and probably old NEEDINFOs 10:27
mcepl_ (that could be much easier than NEW bugs) 10:28
j6k mcepl_: something like "this issue has been in NEEDINFO for > 30 days, closing now"? 10:28
* poelcat continues to think leaving the "easy" stuff for newbies is better 10:29
poelcat and those more comfortable w/ the process work on NEW 10:29
jds2001 poelcat: agreed 10:29
j6k poelcat: you have a point there 10:29
poelcat so.. how about a short term goal for next week? 10:29
jds2001 but someone has to get the newbies going :) 10:29
poelcat how about if everyone tries to triage 25 NEW bugs? 10:30
poelcat is that asking too much? 10:30
mcepl_ j6k: well, before that a) check that it actually wasn't answered ( b) "if you want's answer in the another 30 days, we'll close it" 10:30
mcepl_ s/want/won't/ 10:30
jds2001 mcepl_: i exercise discretion there 10:30
jds2001 if it was clearly a fire and forget bug, I just close it 10:30
mcepl_ that's the point, why don't think it should be done by robot 10:31
mcepl_ of coruse 10:31
stickster poelcat: A short term goal is a good idea. 10:31
mcepl_ but be very gentle (especially if you are a newbie) 10:31
jlaska is it silly to offer some quick+easy queries to send people to the queue of bugs needing triage (on BugZappers/TakingAction)? 10:31
poelcat or another angle would be can people do 25 bugs or 25 minutes? 10:31
stickster poelcat: It gives new people something to shoot for. 10:31
stickster jlaska: poelcat: I wonder if that could be wrapped up in a more general "shaking out" of the BugZappers page 10:31
stickster *pages 10:32
stickster Which aren't bad to begin with! 10:32
jds2001 hehe you should have seen em when poelcat and I started :) 10:32
jds2001 or rather, *it* :) 10:32
poelcat jlaska: good point! the FindingBugs links is no where on that page :( 10:32
stickster jds2001: I remember -- much improved :-) 10:32
jds2001 do we have a NEEDINFO not modified in 30 days search and/or RSS feed? 10:33
poelcat jds2001: i thought so 10:34
poelcat we should probably move on... so tasks for next week: 10:34
poelcat 1) 25 minutes bugs 10:34
poelcat 2) shake out wiki pages 10:35
mcepl_ jds2001: yeah, 10:35
poelcat let's talk a little about rsc's issue 10:36
poelcat rsc: our meeting is about triaging bugs... how can we do a better job to address what you are raising? 10:37
mcepl_ if there is a patch attached, there should be also keyword Patch, and then we can generate (for individual assignees with their prior approval) weekly reports about low-hanging fruit. 10:38
rsc poelcat: well, maybe Patch or EasyFix or similar things as keyword ignoring by bug triaging? 10:39
jlaska rsc: you're looking for a mechanism for bugs to be flagged such that they'll be skipped for triage? 10:39
poelcat rsc: not sure I understand what you are suggesting 10:39
jds2001 rsc: It's generally gonna be triaging that *sets* those keywords 10:39
jlaska "self triage" ? 10:40
poelcat rsc: you don't want bug triagers to touch bugs? 10:40
rsc poelcat: in perfect cases, yes ;) 10:40
poelcat rsc: hmmm well, that is the whole reason we are meeting :) 10:40
stickster the perfect case is by definition really hard to attain. :-) 10:41
rsc well, my situation is, that the bug triaging touches bug reports which are just ignored by the maintainer. 10:41
rsc it also sets very often e.g. Fedora 9 for Rawhide bugs. 10:42
poelcat rsc: i think those are two separate issues 10:42
rsc poelcat: maybe. But even if a patch or similar solving suggestions are made, the maintainer is often not responsive 10:42
mcepl_ rsc: NO, EasyFix should be used only when it is really an easy fix (typo, forgotten symlink, or something) -- patch (of unknown quality) doesn't make it easy fix. 10:42
poelcat rsc: so you are frustrated that there are comments from bug triagers, but not the maintainer? 10:42
rsc poelcat: both. Maintainer for being lazy and triaging because of closing bugs, changing versions 10:43
mcepl_ rsc: it depends, if you see a lot of bugs from volunteer maintainers, you can try MIA procedure 10:43
poelcat rsc: hmm... we're open to better suggestions on the triage side... we can't "fix the maintainers" :) 10:43
stickster rsc: Let's concentrate on the problem that's relevant to this meeting 10:44
rsc well, changing my explicitly set version to something wrong *is* relevant to this meeting IMHO 10:44
stickster rsc: Right, that's the relevant part 10:44
stickster rsc: Not the fixing maintainers part though 10:44
stickster So let's talk about the changing versions 10:45
rsc e.g. Rawhide -> F9 because of GA is just wrong, even if we're behind the GA a lot of time. 10:45
poelcat rsc: what would you propose instead? 10:45
poelcat previously we did nothing and ended up with a stagnant group of 1,000s of bugs 10:46
mcepl_ rsc: I warn you, there is a long history behind this 10:46
rsc poelcat: leaving the version as it is or making an option to make bug triaging aware about that, that it shouldn't be changed 10:46
poelcat rsc: but 'rawhide' today == F10 bugs 10:46
jds2001 rsc: those version changes are automatic - and have been approved by FESCo 10:47
stickster rsc: I think the first option you suggest, leaving all of them alone, is probably not much of an option. 10:47
poelcat rsc: why is changing the version disruptive to you? 10:47
rsc depends. If a bug isn't solved for F10, it's also Rawhide further on. 10:47
jds2001 rsc: if there's some better suggestion (other than leaving it alone) I'm all ears. 10:47
rsc well, can we make it ignoring if Patch/EasyFix is set? 10:47
poelcat rsc: yes, but they are just like bugs reported against F8 or F9... sadly all of them can't be fixed before EOL 10:48
stickster rsc: So I hear you coming from the perspective not of a maintainer, but as someone who has submitted a fix/patch for a bug 10:48
jds2001 that's feasible, but the patch would apply to F10 in that case 10:48
jds2001 so it deosnt make much sense 10:48
stickster rsc: You don't want the maintainer to be able to avoid fixing it by letting the Rawhide bug become F10, then when F10 goes away, so does the bug 10:48
stickster rsc: Do I understand you correctly? 10:48
rsc stickster: I'm on both ends, maintainer and bug reporter. 10:49
mcepl_ rsc: this is how it was for years (actually F9 GA is the first one when it was done automatically) and the results were very diappointing. 10:49
rsc hmmm 10:50
rsc okay, then I'll have to play tricks further on and update the reports once e.g. version was incorrectly changed 10:50
poelcat mcepl_: what was disappointing? 10:50
mcepl_ if you have sloppy maintainer, you should do something about it (MIA procedure etc) but holding bugs in Rawhide for years is IMHO not a solution (when I started work in Red Hat, I found six years old Rawhide bugs). 10:50
rsc mcepl_: well, AFAIK I've still RHEL bugs open for a similar time now ;) 10:51
rsc mcepl_: MIA for Fedora? 10:51
mcepl_ yeah, and that's the problem which should be resolved somehow (with RHEL bugs things are slightly different -- if there is no customer asking maintainer's head, then it is probably less important) 10:52
mcepl_ rsc: of course 10:52
poelcat mcepl_: right and in a lot of cases those 6 year old bugs were more related to FC1 or FC2 and not current rawhide which is wy I think tracking the GA version is good 10:52
* poelcat notes we have 8 minutes before EOM 10:52
stickster So where does this leave us? Because what I hear is "You should go back to the old way," and we know that didn't work. 10:53
rsc poelcat: I see the point of triaging to catch up non-well bug reports etc. 10:53
mcepl_ poelcat: something like it -- I haven't actually found FC1 bug, but some FC2 I did. 10:53
rsc poelcat: but I really take care of my reports - independent whether they're assigned to me or somebody else. And this is where bug triaging conflicts. 10:53
mcepl_ rsc: and frankly, if the bug is inactive for some time, without much noise being done, then probably not much happens when it is abandoned. We have just so much time and capacity ... 10:54
rsc sorry, that I'm the only one caring about some bugs :) 10:54
stickster rsc: Yes, I think understanding the definition of triage is important 10:55
stickster triage is not to make sick bugs well -- it's to make sure that every sick bug is being checked when it comes in the door, to make sure it's not left in the waiting room 10:55
poelcat anything else we want to cover before EOM or schedule for next week? 10:55
rsc stickster: after talking about, I think, one of the problems is to differ between advanced users and newbies to say it hard. People caring about reports and non-caring is a very big problem. 10:55
stickster But I'm new at this, so I yield 10:55
stickster rsc: You're now back on an issue that's not about triage though :-) 10:56
rsc stickster: I think, it's related. But let me think about it and maybe bring it up again 10:57
jlaska so is this the difference between triaging patients (bugs) as they come into the ER ... versus triaging older bugs to see if they still apply? 10:57
stickster jlaska: Well, I think it also means seeing if someone's been in the waiting room too long 10:57
jlaska doesn't sound like the NEW -> ASSIGNED triage affects rsc much ... but more the triage of possible old/stale bugs? 10:57
stickster Right, and part of the reason for the Rawhide -> F(n) GA transition is to make sure we have an accurate reading of what's wrong in F(n) 10:58
stickster And not simply letting the waiting room fill up beyond capacity 10:58
jlaska ahh ... so NEW bugs that didn't get triaged ... and now we changed to a new F(n) release 10:58
stickster (if that makes sense) 10:58
mcepl_ I think I am with rsc that bug triagers have a nice opportunity to see inactive triagers, but it is not part of the bug triaging per se (it should be really about bugs waiting in the waiting room), and could think about what to do about that. 10:59
* stickster steps aside for smarter, more experienced triage people 10:59
poelcat jlaska: no, all rawhide bugs which are !features or !package reviews change to F10 version in BZ at GA 10:59
poelcat this keeps them relatively attached to a timeframe/release 11:00
stickster poelcat: I don't think there's necessarily a problem with maintainers who purposefully move their bug back to Rawhide for good reason, is there? 11:00
poelcat whereas before like mcepl_ pointed out you had no way of knowing w/ rawhide bugs 11:01
poelcat stickster: nope 11:01
jlaska stickster: good point 11:01
poelcat okay we're at the hour and I have a another meeting :) 11:01
jlaska some might not apply to rawhide ... some might still apply ... only person who might know that ... is an uber-triager ... and the maintainer 11:01
poelcat thanks everyone for coming! 11:01
stickster poelcat: After all, triage doesn't want to get in the way of the maintainer actively involved in that bug 11:02
stickster Thanks poelcat 11:02
jlaska thank you! :) 11:02
stickster jlaska: mcepl_: jds2001: We can move back to #fedora-qa to continue if desired 11:02
poelcat can someone eset the topic for me? 11:02
* poelcat goes AFK 11:02

Generated by 2.7 by Marius Gedminas - find it at!