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.
There is a status, IIRC "NEEDINFO" which puts the ball back in the
reporters court. I don't object to closing some of these (an automated
eMail to the submitter would be nice) if the submitter doesn't care and
the maintainer isn't able to reproduce. In those cases closure would be
a reasonable option.
But in the case of a reproducible problem, perhaps more effort to either
fix the problem or identify the package as having slow/no bugfixes just
to help people find alternatives.
I would fell that "extras" served us well, and a category for packages
with unfixed serious bugs would be appropriate to informed consent. Also
note the WONTFIX disposition I suggested for bugs users can avoid, or
which don't prevent productive usage of an application.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
