Bug backlog - now and future. Some proposals.

[max bianco]

On Mon, Mar 17, 2008 at 10:59 AM, James Kosin <jkosin at beta.intcomgrp.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Todd Denniston wrote:
> | Bill Davidsen wrote, On 03/15/2008 05:37 PM:
> |> Small comments thru the text, rant follows.
> |>
> |> Jon Stanley wrote:
> |>> Hear ye, hear ye!  At the BugZappers meeting that occurred today,
> |>> March 12, 2008, two proposals for dealing with the backlog of bugs,
> | <SNIP>
> |>
> |>> To that end, I am proud to present two proposals, One has to do with
> |>> dealing with the backlog that we have now, and the other has to do
> |>> with making sure we never get into this situation again -- ever. We
> |>> believe that these proposals are the right thing to do, and now is the
> |>> right time to do them, right before a release.
> |>>
> |> I would suggest that the time to fix them is now, *instead* of a
> release. To clear the backlog by *fixing* the bugs, not by writing
> clever scripts to mark them CLOSED:WONTFIX or send notes to bug
> submitters to update the version to keep the bug open (unfixed) for
> another two releases.
> |>
> | <SNIP>
> |>>
> |>> http://fedoraproject.org/wiki/BugZappers/HouseKeeping
> |>> http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
> |>>
> |> I read them, and I find lots of ways to make unfixed bugs exit
> bugzilla, but no indication that bugs will actually be fixed in a more
> timely fashion.
> |>
> |> I think you need a "deadline scheduler" approach, if a bug in a
> package isn't fixed by some (reasonable) time after it's reported, it
> should be evaluated, and unless it's waiting on external info it should
> be marked as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark
> the package as UNMAINTAINED. Then release the UNMAINTAINED packages as a
> separate group in the next release, the way "extras" used to be.
> |>
> |> I believe that maintainers would be motivated to avoid having their
> packages marked UNMAINTAINED, and if they aren't, the description is
> accurate. You would hate to drop a package, but having one with serious
> bugs is worse. You can define "serious" any way you want, users know
> "doesn't work" when they report it.
> |>
> |> In other words, if the package is still usable by most users,
> document the bug as trivial and live with it, and if a major bug isn't
> fixed, the reason doesn't matter. Developers enjoy adding new features
> more than bug fixing, or become too busy to maintain. Good intentions
> are nice, but they don't buy you a beer.
> |>
> |
> | +1, to a point.
> |
> | If the "maintainer" has (reasonably) asked for more information and it
> has been 1 release with no more information coming in, _then_ it would
> be reasonable to close the bug.
> |
> |
> But, iff the release addressed an issue related to the bug report in the
> first place.  Closing a bug just because you don't have any more
> complaints is not really a valid reason.


How long should it be kept open if no more information is forthcoming?


>
> Maybe part of the release process should be to recreate the problem and
> be able to prove the problem is fixed by testing!
>

How do you know the bug is real? The person reporting the bug needs to
provide enough information to reproduce the issue. What is essential info?
I think a bug reporting tool that is integrated into the desktop itself is
going to be required here. The tool could walk a user through the bug
reporting process and maybe insure that appropriate logs are attached by
default, at least we need to ensure that enough info is provided to
reproduce the problem. Sometimes people report as bugs things that are not
bugs and alot of time gets wasted.  If we want  all bugs fixed in a timely
manner then we have to provide  the developers the  means to do so and i
think that means some sort of integrated bug reporting tool that  ensures
that a minimum amount of info is provided for them. How many times has
someone cursed the application only to find that they overlooked something
simple? Everyone has their own custom setup and that can make reproducing a
problem difficult.


Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080317/44e413d9/attachment-0001.htm>