[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: bugzilla triage madness :-/



John Poelstra wrote:
Pekka Savola said the following on 04/04/2008 11:07 AM Pacific Time:
> On Fri, 4 Apr 2008, Michael Schwendt wrote:
>> What do I care? When I filed the bug, the product was fresh and
>> maintained,
>> wasn't it? But more than a year later I'm no longer willing to spend time >> on the same issues without a single sign of life from the package owner.

I think this is completely reasonable. I'd do the same thing and would thus close the bug.

I've been that fortunate to work with exceptionally good people ( so far  ).
Not only has my reports been responded to but responded to very fast.

Which explains all the underlying problem, in a nutshell.

> That seems like one of the fundamental problems here; I agree with you.
> Having filed bugs, and seeing them get closed 5 years later with "this
> product is no longer supported", and no developer response in between is
> rather disheartening.

This raises several important issues that have been masked as the outstanding bug count in Fedora grew and grew until January 2008 when a few of us thought something needed to be done.

1) Do we really have enough package maintainers?
  --If not, why?
  --Will we ever?
  --Is this the wrong issue to focus on?

Yes, this is the wrong issue to focus on.
It's the quality of the maintainer(s) and packages not the quantity..
2) Is it reasonable for a bug reporter or a maintainer to expect that EVERY legitimate bug filed will be fixed?
No but he expects to be responded to ( no later then a month I would say ) even more so if he bother to patch the issue and submit it...
   --If not, how does Fedora as project adjust bug reporter expectations?
When filing a new bug show top packages that aren't worth filing against because they wont be responded to anyway. If reporter reports against these packages/applications he *knows* he's not getting response.

--Could Fedora provide guidelines around which types of bug reports are more desirable than others--assuming bug reporters have finite time as well?

All bugs are equal, whether they are big or small, incorrect file permissions or segmentation faults ...
3) With finite resources is it wiser to attempt to fix all the bugs in Fedora Core 1 to 6 or polish Fedora 9? --The EOL releases have definitely been a distraction and potential time waster for new triagers

In a perfect bugzilla world triagers would not be needed at all..
4) Is it actually a *better* user experience to routinely close open bugs that aren't getting fixed then let them sit for several years with no response? In other words is it better to disappoint someone a month or two after reporting a bug or a year?

Nope and it would not be needed if there were any response to the bug in the first place.

How about some stats about which packages/components have not responded
to reports against them..

So how to solve..

( No I dont just wine about how broken things are I also try to come up with a solutions, problems are meant to be solved..)

A simple email reminder to maintainer/developer that he has not responded to a bug, once a month maybe..

Add a info field that the package/component in bugzilla which maintainers(s)/developer(s) fills out which contains what he/they want from a reporter and how to get it( log files etc. debug mode strace etc.) and that info box is displayed when filling a report to that package/component.

Good for better reports/ and new testers to know what to give.
( New testers need responses and guides. if we are gonna keep them reporting. )

Best regards
                Johann B.
begin:vcard
fn:Johann B.  Gudmundsson
n:Gudmundsson;Johann B. 
org:Reiknistofnun - University of Iceland;IT Management
adr:Dunhagi 5;;Taeknigardur;Reykavik;;107;Iceland
email;internet:johannbg hi is
title:Unix System Engineer RHCE,CCSA
tel;work:+3545254267
tel;fax:+3545528801
tel;pager:N/A
tel;home:N/A
tel;cell:N/A
url:http://www.rhi.hi.is
version:2.1
end:vcard


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]