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 http://tinyurl.com/4cavl2 | 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 | http://tinyurl.com/5cr3vs | 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 | http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ASSIGNED | 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 -- http://tinyurl.com/6cvkcp | 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 (https://bugzilla.redhat.com/show_bug.cgi?id=213941) 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, http://tinyurl.com/5jofkn | 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 irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!