unhandled bugs in bugzilla

[Havoc Pennington]

On Tue, Jul 29, 2003 at 08:44:08PM -0400, Jay Berkenbilt wrote: 
> Please understand that I am asking this as an honest question.  I
> sincerely appreciate the effort that goes into making these releases,
> and understand that a lot of people are up to their ears in work.  I
> mean this message as an expression of concern and request for advice
> rather than as a complaint or a nag.  For example, could there be a
> problem that certain products' default bug owners are no longer there
> or are not as responsive as they should be?  Could it be that some
> people are in the habit of paying attention to their bugs but not
> accepting them so that their state turns into ASSIGNED?  We use
> bugzilla in house for our own bug tracking.  I encourage my people to
> click on the "My Bugs" link regularly to make sure they haven't missed
> anything.  We don't have the daily nag messages for stale NEW bugs
> enabled, but I bet enabling that would help somewhat.  I'd like to
> figure out a way of making sure bugs I report don't get ignored
> without becoming a pest.

This is a really awesome question, and improving bug handling is
hopefully one of the things that will happen as a result of opening up
the distribution project.

I'd recommend reading this article:
 http://archive.linuxsymposium.org/ols2003/Proceedings/All-Reprints/Reprint-Villa-OLS2003.pdf

The article points here which is good too:
 http://developer.gnome.org/projects/bugsquad/triage/

See also these reports:
 http://bugzilla.gnome.org/reports.cgi
 http://bugzilla.gnome.org/gnome-23-report.html

Basically the answer I would suggest to your question is:

 - more help for developers identifying highest priority/severity bugs

 - consistent policy and standards for which are high priority (this
   is not an intrinsic property of the bug, rather a function of the
   release in progress and the other bugs that exist)

 - consistent policy for how the NEW, ASSIGNED, MODIFIED,
   etc. resolutions are used

 - tracking bugs with patches
   (for example http://bugzilla.gnome.org/gnome-23-report.html)

 - tracking bugs that anyone can easily fix, especially important once
   we figure out how to open up cvs (basically all the "just fix some
   small spec file glitch" type of bugs - we have a keyword for this
   already)

 - helping identify critical bugs, as in the two tracking bugs Bill
   posted about; these are the really-really-should-fix and should-fix
   bug lists.

 - later in the process we usually create a "stop ship" list of bugs
   we'd delay release for, a bug has to be _bad_ for this and the list
   is typically short

 - helping close noncritical bugs as WONTFIX, NOTABUG, or UPSTREAM

 - report the bugs to upstream bug trackers, when closing UPSTREAM

 - documenting bug tracking and how it works

If you have bugs that haven't been touched, probably they are either
newer than the last release and no triage has occurred yet, or they
didn't make it onto one of the release critical lists either by
conscious decision or by slipping through the cracks.

If a bug doesn't make it onto the must-fix or should-fix list for a
release, it may get fixed, but typically not. Some developers will
leave it open forever to avoid having an argument (bad), some 
will WONTFIX or UPSTREAM the bug (good).

Anyway, hopefully this gives you some idea how people can help with
using bugzilla more effectively.

Havoc