286129 - Bugzilla nagging of bugfix management considered inadequate.

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect)

Description

[Kent Paul Dolan]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050313
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050313

The may be related to the discussion in Bug 13534,
but isn't the same bug.

At the example URL, notice a Mozilla bug "accepted"
for repair in 10/2001, and still just sitting there
more than three years later.

I have no clue whether the problem is a process
improvement one, or a (bugzilla) software
enhancement one, so if this is the wrong venue, some
kind soul please repost this appropriately.

I think several things aren't happening, to allow
bugs to just "float" for years on end:

1) Bug managers aren't being nagged proactively by
Bugzilla about bugs with no reported progress over
long durations, where "30 days" is probably a "long
duration".

2) Bug severity doesn't contain a "how long has this
been unresolved" component to the bug severity
field. Bugs should, IMO, age to be labeled as more
severe, with time, to sharpen management focus on
old bugs that aren't getting needed fixes and may
need reassigning.

3) Managers need to worry more about bugs as fixes
keep not appearing, and bugzilla "needs" to help
keep them worried. This critical Mozilla bug, for
example, is now in its fifth calendar year, and
still annoying users with loss of data:

https://bugzilla.mozilla.org/show_bug.cgi?id=63292

yet the fix, if difficult, is still straightforward,
and well known, use of a "two-phase commit" protocol
for updating Mozilla's history, and is one any
skilled database management system software author
could probably do blindfolded, yet lots of other
stuff has been tried and failed, instead.

To succeed, software suites need to give the
appearance to the end user community that problems
get fixed. Bugzilla in turn needs to do all it can
to contribute to that happening.

I'll suggest an analysis be done "here" in the
Bugzilla community  to see if Bugzilla could be
doing more to assure that bugs don't "linger
unnoticed and unremedied" for such prolonged
intervals, since a prime purpose of bug tracking
software is to help software development management
implement bugfix timeliness accountability as part
of the bug tracking process.

In particular, "accepting" a bug might include input
of an anticipated repair date (and means to modify
that later if needed, such modifications being
highlighted automatically to component management),
and warnings to component management if that date is
exceeded.

Lots of other designs are also possible.

FWIW

xanthian.



Reproducible: Didn't try

Steps to Reproduce:
1. Assign a bug.
2. Watch it not get fixed for years.
3.

Actual Results:  
[I didn't] Nothing happened; that's more or less the point.

Expected Results:  
Bugs get fixed before they are old enough to enter grade school.


I have an attitude problem. That doesn't really change the
correctness of the bug report, just its wording.

Comment 1

[Max Kanat-Alexander]

Hey Xanthian. I do appreciate your concern for the process, and there are
definitely problems.

However, this seems like a bugzilla.mozilla.org specific issue, overall. The
features to handle this are already in the Bugzilla product itself, they would
just have to be used.

By the way, you can always tell how long a bug has been unresolved by seeing how
low the bug number is.

Comment 2

[Gervase Markham [:gerv]]

Automatic nagging doesn't magically create more developer time. I've not heard oof any demand from developers for nagging on b.m.o., so resolving WONTFIX.

Gerv

Comment 3

[Kent Paul Dolan]

You have bugs, like bug 63292, that are critical
data loss bugs, yet old enough now to enter grade
school. The point of a nag process isn't to "magic
up" extra maintainer time, but to refocus
maintainer efforts so that bugs are repaired in a
timely manner. Your "wontfix" was an irresponsible
decision that will leave your products forever with
lingering, unrepaired bugs, destroying the reputation
of your product and of your product support, and
artificially inflating the level of bugs that have to
be received and evaluated as "duplicates" that would
otherwise not exist because the repair had been made
years ago. In the end, your decision unnecessarily
_wastes_ developer resources at the bug triage stage.

xanthian.