From Fedora Project Wiki

Revision as of 07:51, 18 September 2016 by Jibecfed (talk | contribs) (internal link cleaning)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

-!- poelcat changed the topic of #fedora-meeting to: Bug Triage Meeting 07:00
mcepl_ hi 07:00
poelcat who is around/ 07:00
* jlaska 07:00
poelcat mcepl_: hi! 07:01
* j6k is around 07:01
* jds2001 07:01
poelcat welcome: jlaska j6k jds2001 07:01
jlaska Greetings! 07:02
* axelilly is a round 07:02
* j6k believes this is his first bugzapper meeting 07:02
jlaska mine as well :) 07:02
jds2001 welcome :) 07:02
j6k thanks 07:02
poelcat let's wait 60 seconds and then we'll start 07:02
mcepl_ how come there is 112 users in this channel -- do we have that many bugzappers? 07:03
* jds2001 has been consumed wiht $DAYJOB over the last week (and is likely to continue for awhile) 07:03
poelcat jds2001: we've got you covered :) 07:03
jds2001 mcepl_: lots of folks (including me) idle here 24/7 :) 07:03
jds2001 welcome stickster :) 07:04
* stickster here 07:04
stickster ...between phone calls to contractor. 07:04
poelcat alrighty 07:04
jds2001 ouch, still working on the kitchen? :/ 07:04
poelcat next week i will have matrix of tasks we are working on 07:05
poelcat this week I thought we could start by talking about how triage NEW rawhide bugs is going 07:05
jds2001 there aready is one woefully out of date :/ 07:05
poelcat looking at http://tinyurl.com/4cavl2 07:05
stickster jds2001: It's the upstairs bathroom now. 07:05
poelcat we lost a tiny bit of ground 07:05
* jlaska clicks 07:05
poelcat in that I think last week we were at 1404 NEW and now closer to 1450 07:06
poelcat have folks had any issues/questions triaging those bugs? 07:06
poelcat the goal I proposed last week was trying to get that number much lower as the test releases approach 07:07
* poelcat starts singing "all by myself" and queues up "is anybody out there?" 07:07
jds2001 lol 07:08
jlaska :) 07:08
jds2001 http://tinyurl.com/5cr3vs 07: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. 07:08
jds2001 132 filed last week 07:09
stickster poelcat: I tried to triage a few in the last week. 07:09
stickster poelcat: It was a trivially tiny effort on my part, but it made me more confident about doing some more this week. 07:09
jlaska what if we add focus triage efforts specific to new features? 07:09
jlaska s/add// 07:09
* poelcat isn't sure if mcepl_ is being sarcastic or serious 07:09
mcepl_ poelcat: very sarcastic, of course 07:09
jds2001 stickster: did you have any issues? 07: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. 07:10
stickster jds2001: I think that could be a little clearer on the wiki pages. 07:10
* stickster hasn't triaged before, so he could look at it fairly with completely fresh eyeballs. 07:11
poelcat http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ASSIGNED 07:11
poelcat stickster: yes, the focus of NEW bugs is really just to make sure there is enough information present to work on it 07:12
poelcat and that it really should be there 07:12
mcepl_ I think we should write pretty clearly, that so far 90% of all work are NEW bugs and old NEEDINFO bugs. 07:12
mcepl_ stickster: and if possible you should try to reproduce it 07:12
* jds2001 saw a question on IRC while I was in a horizontal posistion about packages that we dont ship 07: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 07:12
jds2001 but they left before I could answer 07: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...}." 07: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 07: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 07:15
poelcat jlaska: no, not at all... i've found I can triage 20 or 30 bugs in 30 minutes 07:15
jlaska wow ... nm :) 07:15
ecntr1 <eof> 07:16
poelcat stickster: being newly exposed to this process... do you see any ways the docs and getting started stuff could be clearer 07: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.) 07:16
poelcat some way to better convey what can be done 07:16
poelcat rsc: hi, could we cover your concerns in a little bit? 07:17
rsc poelcat: of course 07: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? 07:19
poelcat approx 1 month from now 07:20
poelcat j6k: have you had any good/bad experiences triaging bugs so far? 07: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. 07:21
* stickster returns -- sorry, had to get back on the phone. 07:22
j6k poelcat: had a phone-call, back now 07:23
stickster poelcat: The best way to document something, I find, is to be absolutely clear what you assume people know. 07:23
j6k i started by looking for duplicates in NEW issues and that worked quite well 07:23
mcepl_ poelcat: on the other hand, when I dive into some Firefox bugs, I can easily spend couple of hours on it. 07:23
stickster poelcat: Without that assessment, you can't know how much you need to explain. 07:24
poelcat stickster: so we could improve this page BugZappers/TakingAction 07:24
mcepl_ BTW, to show my former lawyer's nature -- http://tinyurl.com/6cvkcp 07:24
mcepl_ (this is the list of my Rawhide NEW bugs) 07: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. 07:26
poelcat okay so before we move on... does everyone continue to agree that NEW rawhide bugs is our first focus and goal? 07:26
mcepl_ I think so 07:26
jlaska poelcat: yeah 07:27
* j6k agrees 07:27
jds2001 yeah 07:27
mcepl_ and probably old NEEDINFOs 07:27
mcepl_ (that could be much easier than NEW bugs) 07:28
j6k mcepl_: something like "this issue has been in NEEDINFO for > 30 days, closing now"? 07:28
* poelcat continues to think leaving the "easy" stuff for newbies is better 07:29
poelcat and those more comfortable w/ the process work on NEW 07:29
jds2001 poelcat: agreed 07:29
j6k poelcat: you have a point there 07:29
poelcat so.. how about a short term goal for next week? 07:29
jds2001 but someone has to get the newbies going :) 07:29
poelcat how about if everyone tries to triage 25 NEW bugs? 07:30
poelcat is that asking too much? 07:30
mcepl_ j6k: well, before that a) check that it actually wasn't answered (https://bugzilla.redhat.com/show_bug.cgi?id=213941) b) "if you want's answer in the another 30 days, we'll close it" 07:30
mcepl_ s/want/won't/ 07:30
jds2001 mcepl_: i exercise discretion there 07:30
jds2001 if it was clearly a fire and forget bug, I just close it 07:30
mcepl_ that's the point, why don't think it should be done by robot 07:31
mcepl_ of coruse 07:31
stickster poelcat: A short term goal is a good idea. 07:31
mcepl_ but be very gentle (especially if you are a newbie) 07:31
jlaska is it silly to offer some quick+easy queries to send people to the queue of bugs needing triage (on BugZappers/TakingAction)? 07:31
poelcat or another angle would be can people do 25 bugs or 25 minutes? 07:31
stickster poelcat: It gives new people something to shoot for. 07:31
stickster jlaska: poelcat: I wonder if that could be wrapped up in a more general "shaking out" of the BugZappers page 07:31
stickster *pages 07:32
stickster Which aren't bad to begin with! 07:32
jds2001 hehe you should have seen em when poelcat and I started :) 07:32
jds2001 or rather, *it* :) 07:32
poelcat jlaska: good point! the FindingBugs links is no where on that page :( 07:32
stickster jds2001: I remember -- much improved :-) 07:32
jds2001 do we have a NEEDINFO not modified in 30 days search and/or RSS feed? 07:33
poelcat jds2001: i thought so 07:34
poelcat we should probably move on... so tasks for next week: 07:34
poelcat 1) 25 minutes bugs 07:34
poelcat 2) shake out wiki pages 07:35
mcepl_ jds2001: yeah, http://tinyurl.com/5jofkn 07:35
poelcat let's talk a little about rsc's issue 07:36
poelcat rsc: our meeting is about triaging bugs... how can we do a better job to address what you are raising? 07: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. 07:38
rsc poelcat: well, maybe Patch or EasyFix or similar things as keyword ignoring by bug triaging? 07:39
jlaska rsc: you're looking for a mechanism for bugs to be flagged such that they'll be skipped for triage? 07:39
poelcat rsc: not sure I understand what you are suggesting 07:39
jds2001 rsc: It's generally gonna be triaging that *sets* those keywords 07:39
jlaska "self triage" ? 07:40
poelcat rsc: you don't want bug triagers to touch bugs? 07:40
rsc poelcat: in perfect cases, yes ;) 07:40
poelcat rsc: hmmm well, that is the whole reason we are meeting :) 07:40
stickster the perfect case is by definition really hard to attain. :-) 07:41
rsc well, my situation is, that the bug triaging touches bug reports which are just ignored by the maintainer. 07:41
poelcat rsc: i think those are two separate issues 07:42
rsc it also sets very often e.g. Fedora 9 for Rawhide bugs. 07:42
rsc poelcat: maybe. But even if a patch or similar solving suggestions are made, the maintainer is often not responsive 07: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. 07:42
poelcat rsc: so you are frustrated that there are comments from bug triagers, but not the maintainer? 07:42
rsc poelcat: both. Maintainer for being lazy and triaging because of closing bugs, changing versions 07:43
mcepl_ rsc: it depends, if you see a lot of bugs from volunteer maintainers, you can try MIA procedure 07:43
poelcat rsc: hmm... we're open to better suggestions on the triage side... we can't "fix the maintainers" :) 07:43
stickster rsc: Let's concentrate on the problem that's relevant to this meeting 07:44
rsc well, changing my explicitly set version to something wrong *is* relevant to this meeting IMHO 07:44
stickster rsc: Right, that's the relevant part 07:44
stickster rsc: Not the fixing maintainers part though 07:44
stickster So let's talk about the changing versions 07:45
rsc e.g. Rawhide -> F9 because of GA is just wrong, even if we're behind the GA a lot of time. 07:45
poelcat rsc: what would you propose instead? 07:45
poelcat previously we did nothing and ended up with a stagnant group of 1,000s of bugs 07:46
mcepl_ rsc: I warn you, there is a long history behind this 07: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 07:46
poelcat rsc: but 'rawhide' today == F10 bugs 07:46
jds2001 rsc: those version changes are automatic - and have been approved by FESCo 07:47
stickster rsc: I think the first option you suggest, leaving all of them alone, is probably not much of an option. 07:47
poelcat rsc: why is changing the version disruptive to you? 07:47
rsc depends. If a bug isn't solved for F10, it's also Rawhide further on. 07:47
jds2001 rsc: if there's some better suggestion (other than leaving it alone) I'm all ears. 07:47
rsc well, can we make it ignoring if Patch/EasyFix is set? 07: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 07: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 07:48
jds2001 that's feasible, but the patch would apply to F10 in that case 07:48
jds2001 so it deosnt make much sense 07: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 07:48
stickster rsc: Do I understand you correctly? 07:48
rsc stickster: I'm on both ends, maintainer and bug reporter. 07: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. 07:49
rsc hmmm 07:50
rsc okay, then I'll have to play tricks further on and update the reports once e.g. version was incorrectly changed 07:50
poelcat mcepl_: what was disappointing? 07: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). 07:50
rsc mcepl_: well, AFAIK I've still RHEL bugs open for a similar time now ;) 07:51
rsc mcepl_: MIA for Fedora? 07: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) 07:52
mcepl_ rsc: of course 07: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 07:52
* poelcat notes we have 8 minutes before EOM 07: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. 07:53
rsc poelcat: I see the point of triaging to catch up non-well bug reports etc. 07:53
mcepl_ poelcat: something like it -- I haven't actually found FC1 bug, but some FC2 I did. 07: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. 07: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 ... 07:54
rsc sorry, that I'm the only one caring about some bugs :) 07:54
stickster rsc: Yes, I think understanding the definition of triage is important 07: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 07:55
poelcat anything else we want to cover before EOM or schedule for next week? 07: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. 07:55
stickster But I'm new at this, so I yield 07:55
stickster rsc: You're now back on an issue that's not about triage though :-) 07:56
rsc stickster: I think, it's related. But let me think about it and maybe bring it up again 07: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? 07:57
stickster jlaska: Well, I think it also means seeing if someone's been in the waiting room too long 07:57
jlaska doesn't sound like the NEW -> ASSIGNED triage affects rsc much ... but more the triage of possible old/stale bugs? 07: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) 07:58
stickster And not simply letting the waiting room fill up beyond capacity 07:58
jlaska ahh ... so NEW bugs that didn't get triaged ... and now we changed to a new F(n) release 07:58
stickster (if that makes sense) 07: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. 07:59
* stickster steps aside for smarter, more experienced triage people 07:59
poelcat jlaska: no, all rawhide bugs which are !features or !package reviews change to F10 version in BZ at GA 07:59
poelcat this keeps them relatively attached to a timeframe/release 08: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? 08:00
poelcat whereas before like mcepl_ pointed out you had no way of knowing w/ rawhide bugs 08:01
poelcat stickster: nope 08:01
jlaska stickster: good point 08:01
poelcat okay we're at the hour and I have a another meeting :) 08: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 08:01
poelcat thanks everyone for coming! 08:01
stickster poelcat: After all, triage doesn't want to get in the way of the maintainer actively involved in that bug 08:01
stickster Thanks poelcat 08:02
jlaska thank you! :) 08:02
stickster jlaska: mcepl_: jds2001: We can move back to #fedora-qa to continue if desired 08:02
poelcat can someone eset the topic for me? 08:02
* poelcat goes AFK 08:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!