From Fedora Project Wiki

Bug Triage Meeting :: 2009-04-07


  • adamw
  • poelcat
  • john5342
  • beland
  • mcpel
  • tk009
  • Sonar_Guy
  • comphappy
  • arxs


  • Should a check for bugs filed in upstream Bugzillas be mandatory: No decision was reached, however, a guideline was proposed. "triagers are encouraged to check upstream for similar reports and take appropriate action according to the preferences of the component's maintainers."
  • NEEDINFO: Discussion on the time a bug should remain flagged as NEEDINFO before being closed. Consensus couldn't be reached on a change to the current policy.
  • Triage Metrics: comphappy will have a beta version of the triage metrics up by 9 April, and should be operational for testing no later than 16 April. Fully operational triage metrics will be in place no later than 6 May.

Follow Up Action

  • comphappy will email fedora-test-list with the link for the metrics beta and where to address bug reports.
  • adamw will email fedora-devel-list for feedback on bug severity/priority settings with a view to guide triagers in correctly setting these fields when a bug is triaged.
  • Tk009 will compare all the GreaseMonkey script response output to the standard responses page for uniformity.

IRC Transcript

---poelcat has changed the topic to: Bug Triage Meeting Apr 07 11:02
poelcat who do we have today? Apr 07 11:02
poelcat ping adamw: mcepl beland jds2001 tk009 Apr 07 11:02
poelcat tk009: welcome back! Apr 07 11:02
adamw pong Apr 07 11:02
mcepl here Apr 07 11:02
John5342 hi Apr 07 11:02
comphappy here Apr 07 11:02
poelcat John5342: comphappy hi :) Apr 07 11:03
arxs hello Apr 07 11:03
*Sonar_Guy lurks Apr 07 11:03
*poelcat knew i was missing a few Apr 07 11:03
poelcat welcome arxs and Sonar_Guy Apr 07 11:03
adamw indeed Apr 07 11:03
*poelcat scrables to locate the agenda Apr 07 11:03
---dwmw2_SFO is now known as dwmw2_gone Apr 07 11:04
poelcat topic #1... User:Beland/How_to_Triage to replace BugZappers/ Apr 07 11:04
poelcat discussion points were in agenda Apr 07 11:04
poelcat not sure if we want to go point by point Apr 07 11:05
poelcat any feedback or points people want to disucss? Apr 07 11:05
comphappy Thank you beland for doing that it looks really good Apr 07 11:05
adamw yep...we went over it in detail last week, i think it's pretty awesome now Apr 07 11:06
<--tatica has quit (Remote closed the connection) Apr 07 11:06
adamw arxs or sonar_guy, have you seen it? what did you guys think of it? Apr 07 11:06
Sonar_Guy reading now Apr 07 11:06
comphappy I wonder if things like User:Beland/How_to_Triage#Easier_Testing_on_Different_Fedora_Versions should be in a different section/page Apr 07 11:06
comphappy and expanded there Apr 07 11:06
adamw we were talking about the separate page thing last week...i was in the all-one-big-page camp, but that section does strike me as one that could be split out Apr 07 11:07
-->tatica (n=tatica@nelug/designer/tatica) has joined #fedora-meeting Apr 07 11:07
adamw although it's not really that big, and i don't see how it could take much expanding - it's mostly just a reference to the qemu page Apr 07 11:07
comphappy I feel that it does not add anything in its current state. Apr 07 11:08
poelcat i proposed this split Apr 07 11:08
poelcat where #1 and #2 would be two separate pages Apr 07 11:08
adamw i could live with that...i dunno, either's fine for me Apr 07 11:09
poelcat did we answer these questions: Should a check for bugs filed in upstream Bugzillas be mandatory? (conflicting opinions so far) * Should NEW triagers be asked to do NEEDINFO updates in 30 and 60 days if needed, or should this be left to triagers following the NEEDINFO checklist? (Beland doesn't, other people do) Apr 07 11:09
comphappy Also I do not think we ref this page anywhere which is important BugZappers/Components_and_Triagers Apr 07 11:10
poelcat anyone? Apr 07 11:11
poelcat Should a check for bugs filed in upstream Bugzillas be mandatory? (conflicting opinions so far) Apr 07 11:11
adamw i vote yes. Apr 07 11:11
tk009 why yes? Apr 07 11:11
tk009 I vote no Apr 07 11:11
adamw ahh, conflict! Apr 07 11:11
adamw :) Apr 07 11:11
<--drago01 has quit (Read error: 110 (Connection timed out)) Apr 07 11:11
tk009 =) Apr 07 11:11
adamw hmm, lemme think. well, i guess i could live with no Apr 07 11:12
tk009 no Apr 07 11:12
comphappy I say sometimes Apr 07 11:12
tk009 tell me please Apr 07 11:12
adamw and if we have no consensus we should go with the most conservative option Apr 07 11:12
comphappy it depends on the component Apr 07 11:12
adamw tk009: oh, just because it's useful context, and often the downstream bug is basically a 'dupe' of the upstream and should be resolved Apr 07 11:12
adamw comphappy: it's hard to make something mandatory sometimes =) Apr 07 11:12
comphappy some packages have become so Fedora it is hard Apr 07 11:13
comphappy I have given up reporting java bugs upstream Apr 07 11:13
poelcat mcepl: what do you think? Apr 07 11:14
comphappy also when the bug has not been confirmed that is an issue as well Apr 07 11:14
mcepl sorry, a sec Apr 07 11:14
poelcat beland: did you have a leaning one way or the other? Apr 07 11:15
comphappy someways I think this might be something that *ducks* falls on the packager/maintainer Apr 07 11:15
<--nicubunu has quit (Remote closed the connection) Apr 07 11:15
comphappy something is filed as a bug against one of my packages I go and do it Apr 07 11:15
mcepl very resolute "It depends" ;) Apr 07 11:15
mcepl you need to talk with Fedora maintainers, how do they want to deal with upstream bugs Apr 07 11:15
arxs i think that packages who have an active triager should be look upstream for this bugs Apr 07 11:16
*poelcat can see how it is something that *might* help the maintainer, but it adds more time to the triager, though some could argue the triager should be familiar w/ upstream :-/ Apr 07 11:16
adamw i think "it depends" is basically "no", because if it's not always necessary then it's not mandatory Apr 07 11:16
mcepl e.g., ajax keeps all bugs in b.r.c, caillon pushes everything upstream Apr 07 11:16
John5342 some maintainers look at the bug and if appropriate ask the reporter to report upstream and add the upstream bug to bog Apr 07 11:16
<--mharris has quit () Apr 07 11:16
mcepl this is the situation where we just serve maintainers to do what they want to do Apr 07 11:16
arxs i think that the active triagers knows the software very well, and maybe also the bugs in upstream Apr 07 11:16
<--valente has quit ("Leaving.") Apr 07 11:17
comphappy for some if not many of the packages I dont think even the maintainers know all the bugs going on upstream Apr 07 11:17
adamw maybe we should say something like "triagers are encouraged to check upstream for similar reports and take appropriate action according to the preferences of the component's maintainer" or something like that Apr 07 11:17
comphappy adamw: +1 Apr 07 11:17
*mcepl just dreams about knowing well ;-) Apr 07 11:17
adamw mcepl: i think the mozilla guys dream about that as well =) Apr 07 11:18
arxs adamw: sounds good Apr 07 11:18
poelcat adamw: works for me, though a year from now someone will come along to "make the docs better" and argue it was too vague :) Apr 07 11:18
adamw poelcat: and thus glorious progress is made! Apr 07 11:18
poelcat okay next one... Should NEW triagers be asked to do NEEDINFO updates in 30 and 60 days if needed, or should this be left to triagers ? Apr 07 11:18
mcepl and of course, concerning the upstream bugs, mention that if you learn about workarounds etc., you should tell our reporter. Apr 07 11:19
comphappy is the update the hey buddy you going to give us info? If not we are going to close it. Apr 07 11:19
*poelcat not sure Apr 07 11:19
poelcat beland: ? Apr 07 11:20
mcepl comphappy: yes, basically, but very polite one Apr 07 11:20
adamw i don't think he's here... Apr 07 11:20
beland I'm here. Apr 07 11:20
tk009 are you asking should we do our own follow up on NEEDINFO? Apr 07 11:20
adamw this is kind of a philosophical question: are triagers responsible for *bugs as a whole* or *specific processes* Apr 07 11:20
beland Yes. Apr 07 11:20
<--radn has quit (Remote closed the connection) Apr 07 11:20
beland Er, that should be, should triagers do the 30/60 day thing on their own bugs. Apr 07 11:21
adamw i.e. are we traditional craftsmen who follow one loving process from beginning to end, or factory workers who do one little bit of the process over and over again Apr 07 11:21
tk009 if I work on the bug, and flag it needinfo I will follow up on it. Tha doesn't seem a hard thing to do Apr 07 11:21
comphappy I think we need to follow up on it. I have an app i use to keep track of when I need to go back for needinfo an noresponce bugs Apr 07 11:21
adamw not that i carefully constructed that metaphor to favor my own personal opinion or anything =) Apr 07 11:21
beland Personally, I know I might not be around in 30 or 60 days to do the followup, or might not have the time or inclination. Apr 07 11:22
comphappy or just keep a list of what I need to check back on Apr 07 11:22
poelcat beland: "their own bugs" vs. other people's bugs? Apr 07 11:22
comphappy beland: then give someone that list Apr 07 11:22
comphappy it saves people time in the long run Apr 07 11:22
beland I'm also not convinced that it's terribly important to close such bugs; it's fine with me to just leave them in NEEDINFO. Apr 07 11:22
poelcat comphappy: can your app be used by others? Apr 07 11:22
adamw beland: well, maintainers eventually may not be around to maintain their packages, but there are processes to handle that... Apr 07 11:22
adamw i think the rationale for closing needinfo bugs is that if you leave too many open too long it makes the database of open bugs rather unwieldy to search. are there any other considerations? Apr 07 11:23
beland I just assume that if anyone cares, they can do a search for NEEDINFO bugs that have been that way for 30+ days. Apr 07 11:23
*poelcat votes for closing bugs that can't be actioned Apr 07 11:23
comphappy poelcat: sure, it is not really anything big Apr 07 11:23
comphappy simple script + db Apr 07 11:23
adamw is there a reason we can't automate it? Apr 07 11:23
comphappy adamw: that would be really hard Apr 07 11:24
beland It could be that after 30 days, the triager might be willing to attempt to get the missing info themselves. Apr 07 11:24
<--openpercept has quit ("Leaving") Apr 07 11:24
beland e.g. if they didn't try to reproduce in the first place Apr 07 11:24
poelcat why couldn't there be a page in the metrics app of all bugs w/ needinfo > 30 days? Apr 07 11:24
adamw comphappy: how come? I think some bugzillas have bots for it... Apr 07 11:24
comphappy adamw: what are you going to watch Apr 07 11:24
arxs i think that the NEEDINFO should be set, it can shows up, that you need help with that bug, for example, the another one can reprocude it or so one Apr 07 11:25
adamw comphappy: bugs in NEEDINFO which haven't been touched for 30 days Apr 07 11:25
tk009 in bugzilla on your main page it tells you all the needinfo flags you have Apr 07 11:25
mcepl beland: no, we should close them, if we are sure that we won't get response Apr 07 11:25
tk009 what more do you need? Apr 07 11:25
comphappy adamw: think rawhide moving to f11 all the bugs get touched Apr 07 11:25
adamw arxs: the question is who should handle bugs that have been in NEEDINFO for a long time without the info being supplied Apr 07 11:25
mcepl plus, yes, IMHO, you should do it for your bugs, you understand what you need, etc. Apr 07 11:25
beland It makes the commitment for new triagers somewhat long-term. Apr 07 11:26
mcepl and of course, EVERY our action should be done so that when we die tomorrow, somebody will understand what we've done before. Apr 07 11:26
adamw arxs: should the original triager be responsible for following up, or should we see it as a separate task that could be done by a different group of triagers Apr 07 11:26
beland In practice, I'm sure some people won't actually do the followup. Apr 07 11:26
*poelcat doesn't see why it matters who closes NEEDINFO bugs > 30 days Apr 07 11:26
poelcat either the requested info was provided or it wasn't Apr 07 11:26
comphappy poelcat: that is why i said if you cant be here publish the list and then someone else can go clean it up Apr 07 11:26
comphappy not too hard Apr 07 11:27
beland It's more likely that you'll just not be around. Apr 07 11:27
beland Anyone can get a list of NEEDINFO bugs by searching the database. Apr 07 11:27
comphappy yes but ones +30 days can be hard to get Apr 07 11:27
-->mharris (n=mharris@fedora/mharris) has joined #fedora-meeting Apr 07 11:27
adamw hmm, we're spinning wheels here... Apr 07 11:28
mcepl yes, but while doing that "Gimme your info, or else ..." commenting you double-check that the information is necessary, required, etc. Apr 07 11:28
mcepl adamw: yeah, what's the question? Apr 07 11:28
comphappy poelcat: I can look into that, sounds like a good feature, but it is going to hit my FutureFeature list, not the core ones right now Apr 07 11:29
poelcat comphappy: that's fine Apr 07 11:29
adamw i'm just wondering how we're going to get to a consensus on this Apr 07 11:29
poelcat put it at the bottomof th elist Apr 07 11:29
*John5342 wonders how hard it would be to have a batch job done every month similar to eol and other housekeeping tasks. Apr 07 11:29
poelcat let's break this down... Apr 07 11:29
beland Well, a good compromise would be to suggest people do followup on their own bugs, but not make it mandatory. Apr 07 11:29
arxs if we have the option to display all bugs with NEEDINFO older then 30days, we should add an commennt, that we are waiting (maybe 7days) and then close the bug Apr 07 11:29
poelcat 1) can the someone other than the original triager close NEEDINFO > 30 days ? Apr 07 11:30
*poelcat votes yes Apr 07 11:30
John5342 +1 Apr 07 11:30
comphappy +1 i do it already Apr 07 11:30
adamw yes of course Apr 07 11:30
arxs yes Apr 07 11:30
adamw making it the initial reporters responsibility doesn't mean no-one else can do it if that doesn't happen for some reason Apr 07 11:30
*poelcat sees no -1s Apr 07 11:30
mcepl +1 Apr 07 11:30
mcepl (considering that "somebody else" NEVER will be a bot) Apr 07 11:30
poelcat so why can't this be worded that the original triager should close, but so can others ? Apr 07 11:31
tk009 that works just fine Apr 07 11:31
mcepl I am lost ... what document, which paragraph are we talking about? Apr 07 11:31
adamw fine by me Apr 07 11:32
adamw mcepl: i don't think anything's written yet Apr 07 11:32
adamw we wanted to discuss it first Apr 07 11:32
mcepl I see Apr 07 11:32
adamw but it will be part of the 'how to triage' page beland is working on Apr 07 11:32
tk009 just so I am not lost on this tho, dont we give two 30 day periods before closing a needinfo? Apr 07 11:32
poelcat so that takes us to "is this draft ready to be published?" Apr 07 11:32
---knurd_afk is now known as knurd Apr 07 11:32
poelcat tk009: no, just 30 days of no response Apr 07 11:32
poelcat it can always be reopened Apr 07 11:32
*mcepl just wants to emphasize (towards John5342) ... never ever there should be a bot automatically closing old NEEDINFOs. Apr 07 11:33
tk009 I've been giving 60 =) Apr 07 11:33
John5342 mcepl: ok. just a thought. Apr 07 11:33
mcepl tk009: more or less, depends on your consideration Apr 07 11:33
beland User:Beland/How_to_Triage#Checklist_for_NEEDINFO_Bug_Triage says there is a reminder at 30, and closure at 60. Apr 07 11:33
arxs i think 30day, add an comment, that the bug will close shortly Apr 07 11:33
adamw i think the stock text we have implies 30+30 Apr 07 11:33
mcepl John5342: there are many bugs in bugzilla, which make it not remove NEEDINFO flag when it should Apr 07 11:33
poelcat this is getting too complicated Apr 07 11:34
poelcat when set to needinfo you give 30 days Apr 07 11:34
poelcat at the end of 30 days close it Apr 07 11:34
mcepl 30+30 .. there are things like vacations, sickness, etc. Apr 07 11:34
poelcat and it can be reopened Apr 07 11:34
comphappy mcepl +1 Apr 07 11:34
mcepl and it really doesn't add any costs when it lies there in NEEDINFO. Apr 07 11:34
*comphappy has all kinds of ideas about how to simplify these tasks, but not enough time to develop them :/ Apr 07 11:35
*poelcat doesn't want to have to visit the same bug 3 times, 2 would be nicer :) Apr 07 11:35
buggbot Bug medium, medium, ---, dkl, CLOSED WONTFIX, Install errors out if squid already installed. Apr 07 11:35
mcepl :D Apr 07 11:35
mcepl buggbot: good boy! Apr 07 11:36
buggbot mcepl: Error: "good" is not a valid command. Apr 07 11:36
mcepl :D Apr 07 11:36
adamw ahh, endless fun Apr 07 11:36
*poelcat moves to a vote of "30 days then close" Apr 07 11:36
poelcat +1 Apr 07 11:36
tk009 +1 Apr 07 11:36
adamw +/-0 Apr 07 11:37
John5342 0 Apr 07 11:37
comphappy -1 Apr 07 11:37
arxs 0 Apr 07 11:37
mcepl is it 30+0 or 30+30? Apr 07 11:37
mcepl my vote would be - and + for these two? Apr 07 11:37
<--giallu has quit (Connection timed out) Apr 07 11:37
adamw 30+0 is poelcat's proposal, i believe. Apr 07 11:37
mcepl s/\?$/\./ Apr 07 11:37
mcepl -1 Apr 07 11:37
comphappy now that is consensus Apr 07 11:38
adamw =) Apr 07 11:38
adamw we have a perfect consensus of disagreement! Apr 07 11:38
tk009 beland can break that tie Apr 07 11:38
arxs maybe 15+15 ? Apr 07 11:38
comphappy if the concern is vacation, can we just make it 60days does that fix it Apr 07 11:38
beland Mrg... Apr 07 11:38
comphappy so 60+0 Apr 07 11:38
mcepl I think we don't need to have hard rule ... how about letting it on bug triager's agreement with a maintainer? Apr 07 11:39
beland I always feel that having a bug closed out from under me is a bit of a slap in the face, even if it's because I've been slow to reply as the reporter. Apr 07 11:39
beland But it is good to have reminders. Apr 07 11:39
adamw yeah, people do get irritated if you close a bug when they were still actively interested (even if they didn't look it) Apr 07 11:39
beland As a reporter, the 30+30 seems more polite. Apr 07 11:39
poelcat how about 45 days ? :) Apr 07 11:39
mcepl there is commonly followed rule to have 30+something (quite often 30) .... or something Apr 07 11:39
<--rahul_b has quit ("Leaving(पुन्हा भेटू)") Apr 07 11:40
beland I say, if you don't want to visit the same bug 3 times, don't. Let NEEDINFO-only triagers handle it. 8) Apr 07 11:40
*comphappy feels the bike shed should be painted red Apr 07 11:40
poelcat a shorter time frame could be helpful if we are trying to get answers before a release Apr 07 11:40
John5342 comphappy: definately green Apr 07 11:40
mcepl poelcat: moreover that second run through bugs a) doesn't have to be timely ... do it, whenever you have some time for it, b) it is really fast Apr 07 11:40
buggbot Bug medium, medium, ---, dkl, CLOSED WONTFIX, Install errors out if squid already installed. Apr 07 11:40
*adamw would prefer a bike hutch Apr 07 11:40
tk009 looks like we stay 30+30 Apr 07 11:41
comphappy what about 30 days look at it close or extend 30 days depending Apr 07 11:41
*poelcat notes it has been 30 days up until now Apr 07 11:41
mcepl poelcat: yes, that's one reason why I don't want to have hard rule ... Rawhide needs faster turnaround and Rawhide reporters' should expect rough treatment Apr 07 11:41
tk009 lol Apr 07 11:42
comphappy also the rawhide bugs can become obsolete within days Apr 07 11:42
adamw BugZappers/StockBugzillaResponses#Unanswered_NEEDINFO_bugs is the current reference, basically Apr 07 11:42
beland It's fine if people use their judgment, but we need default guidance for novices. Apr 07 11:42
mcepl adamw: well, I have also: Apr 07 11:43
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. Apr 07 11:43
tk009 ok so where does this leave us? Apr 07 11:43
adamw yeah, that's the one from the gm script Apr 07 11:43
adamw so right now we have a setup that accurately mirrors our consensus ;) Apr 07 11:43
*poelcat thinks we need a volunteer to compare all the GM output to the standard responses page Apr 07 11:44
*comphappy does think this is effective use of time and we should move to the next topic for the last 15min Apr 07 11:44
beland Sounds like status quo, then. Apr 07 11:44
mcepl beland: for novices, I would definitively left 30+30 (with specific instructions for Rawhide bugs) Apr 07 11:44
mcepl +1 on moving to the next item Apr 07 11:45
-->drago01 ( has joined #fedora-meeting Apr 07 11:45
<--nphilipp has quit ("Leaving") Apr 07 11:45
adamw yeah, let's move on. i like poelcat's idea Apr 07 11:45
beland OK, User:Beland/How_to_Triage#Followup implements the answer to the previous question Apr 07 11:45
poelcat next item is should beland's draft become final and published? Apr 07 11:46
poelcat User:Beland/How_to_Triage to replace BugZappers/ Apr 07 11:46
mcepl beland: +1 to that "it is a good practice" or something of that sort Apr 07 11:46
mcepl +1 with further bug fixing in the document as necessary Apr 07 11:46
adamw yeah, i think we can kick it out there now Apr 07 11:47
*poelcat +1 Apr 07 11:47
arxs +1 Apr 07 11:47
poelcat anyone not in favor of moving forward? Apr 07 11:47
poelcat okay, thanks beland for all your work (and patience with us) on this! Apr 07 11:48
beland ::whew:: Apr 07 11:48
poelcat next topic... triage metrics Apr 07 11:48
comphappy I just got resources approved Apr 07 11:48
poelcat comphappy has been doing some work to move everything into fedora infrastructure Apr 07 11:48
poelcat comphappy: take it away :) Apr 07 11:48
-->jreznik_eee (n=jreznik@nat/redhat/x-1d691bec2bc3f2e8) has joined #fedora-meeting Apr 07 11:48
poelcat comphappy: what are our target dates? Apr 07 11:49
comphappy the beta site should go live in the next two days Apr 07 11:49
comphappy by next week it will be usable Apr 07 11:49
comphappy then i need feedback Apr 07 11:49
poelcat comphappy: how long should the beta period be? Apr 07 11:49
comphappy depends on how it is acting Apr 07 11:50
poelcat we've had a long alpha :) Apr 07 11:50
comphappy I have until 06/06/09 to push it live Apr 07 11:50
<--J5 has quit (Read error: 110 (Connection timed out)) Apr 07 11:50
poelcat comphappy: let's pick a date, if it doesn't work we can decide then Apr 07 11:50
poelcat how about may 1st ? Apr 07 11:50
comphappy May 6 Apr 07 11:50
poelcat :) Apr 07 11:50
-->J5 (n=quintice@nat/redhat/x-1326dd210b2b9d6c) has joined #fedora-meeting Apr 07 11:50
comphappy poelcat: I have AP test coming up and that is going to suck time Apr 07 11:51
-->yunustj (n=yunusf10@fedora/yunustj) has joined #fedora-meeting Apr 07 11:51
poelcat anyone else have strong feelings on targeted GA date? Apr 07 11:51
adamw i'd like to be a bit aggressive Apr 07 11:51
poelcat comphappy: with that in mind is 6-may realistic? Apr 07 11:51
comphappy yea Apr 07 11:51
adamw it's going to be an important tool for bugzappers and qa in general Apr 07 11:51
<--jreznik_eee has quit (Read error: 60 (Operation timed out)) Apr 07 11:52
adamw and it's not a big deal if it has a bit of a problem - i doubt it's going to do anything critical, it can't eat any data that it didn't produce in the first place, and i guess it'd be highly unlikely that it'd produce bogus results at all Apr 07 11:52
adamw so i don't see that anything particularly serious can go wrong with it Apr 07 11:52
poelcat comphappy: so once the beta is running, can you send an email to f-test-l with instructions on where to go use it and file bugs? Apr 07 11:52
comphappy yes, also here is the rfr that I submitted for anyone who wants to read Apr 07 11:53
comphappy move on to bugzilla legend? Apr 07 11:53
beland (BugZappers/How_to_Triage has been updated with the new content) Apr 07 11:53
-->jreznik_eee (n=jreznik@nat/redhat/x-8cf4af38e5ea1f09) has joined #fedora-meeting Apr 07 11:53
beland Sure... Apr 07 11:53
beland So, adamw is going to draft a letter... Apr 07 11:54
poelcat that page looks like it is still under construction to me Apr 07 11:54
poelcat not ready to review Apr 07 11:54
adamw what page? Apr 07 11:54
comphappy User:Beland/Bugzilla_Legend Apr 07 11:55
beland Yeah, we don't have draft language ready to approve. Apr 07 11:55
beland We're waiting for feedback from developers. Apr 07 11:55
comphappy thats fine Apr 07 11:55
beland Which the adamw letter will solicit. Apr 07 11:55
comphappy any other short points to be made? Apr 07 11:55
adamw right - i don't think we need any feedback to expand the definitions for states on the workflow page Apr 07 11:56
poelcat okay so next action is for adam to redraft email to developers? Apr 07 11:56
adamw the big thing is severity/priority, which i'll be asking about Apr 07 11:56
-->Kevin_Kofler ( has joined #fedora-meeting Apr 07 11:56
adamw poelcat: yeah, i'll get that done soon Apr 07 11:56
beland Well, there is some question whether only maintainers should set "UPSTREAM". Apr 07 11:56
adamw yes, but *defining* it doesn't have to involve answering that question =) Apr 07 11:57
beland True, but I assume the same page will also answer that question. Apr 07 11:58
beland And it's something to ask developers, at some point.. Apr 07 11:58
arxs severity is how bad the bug is fore the reporter, and priority indicate how bad it is for the reset i think Apr 07 11:58
beland One meta point...we should remind people to use BugZappers:meeting-agenda-list to add agenda items, if that is to be common practice. Apr 07 11:59
adamw sure, but for now i plan to avoid it =) we have enough controversy Apr 07 11:59
arxs or missed the question? Apr 07 11:59
beland Not a bad plan, adamw. Apr 07 11:59
adamw arxs: what's happening on that is i'm going to ask the developers whether they'd like to use those fields and if so what for Apr 07 11:59
*poelcat notes 30 seconds until closing Apr 07 11:59
adamw arxs: because the main point of triage is to assist the developers, so we should go with their preferred option. Apr 07 11:59
Sonar_Guy quick question which channel do most of you hang out in? Apr 07 12:00
poelcat we need to end and make way for the KDE Kontingent Apr 07 12:00
poelcat adamw: bug day in #fedora-bugzappers? Apr 07 12:01
<--John5342 has quit (Remote closed the connection) Apr 07 12:01
tk009 fedora-bugzappers Sonar_Guy Apr 07 12:01
<--tatica has quit (Read error: 104 (Connection reset by peer)) Apr 07 12:01
mcepl adamw: general consensus I have ever heard is that they are useless. Apr 07 12:01
Sonar_Guy ok Apr 07 12:01
adamw yep, triage day starts now! Apr 07 12:01
mcepl moving there Apr 07 12:01
poelcat thanks everyone Apr 07 12:02

Generated by 2.7 by Marius Gedminas - find it at!