With the new style of "mass tirage" of bugs,

The user submits a bug;
while (sleep 1 year) {
He gets a message asking him to verify if the bug still exists;
He perhaps especially reinstalls the package that he long ago stopped using &&
He verifies it || the bug is closed
}

Now disposing of those piles of bugs is a breeze, and the maintainer
needn't ever actually look once at the bug! Should cut down on
those annoying new bugs too!

jidanni@jidanni.org writes:

The word is "triage"; it's a term from hospital work.

Who other than the bug reporter would you suggest should try
reproducing the bug?

Suggesting "put that effort into fixing the bugs" is presuming that
the prospective bug fixer knows *which* bugs are worth the effort. If
the bug reporter is unresponsive, the bug is unlikely to be resolved
anyway because it can't be confirmed fixed.

What would you put in place of triage?

Suggesting that the bug simply remain rotting in the BTS seems worse
than subjecting it to triage to determine if it can be discarded.

On Thu, Feb 21, 2008 at 05:11:43AM +0800, jidanni@jidanni.org wrote:

Yeah, it must be really hard to be an heavy bug filer.

* 1552 Outstanding
* 136 Forwarded
* 10 Pending Upload
* 1 Fixed in NMU
* 69 Resolved

On Wed February 20 2008 3:43:18 pm Ben Finney wrote:

I think that the point is that triage should happen at *submission* time, not
so long later.

I have learned that certain well-known packages (OpenOffice, say) are bug
blackholes. I submit a bug, and never hear anything from Debian maintainers
except for periodic triage stuff when a new upstream comes out.

If they suspect it was upstream-related, it should have been forwarded.

But I can't submit OpenOffice bugs upstream because we don't use
OpenOffice.Org's source trees. Sigh.

Please don't send me copies of messages that are also sent to the
list, as I didn't ask for them.

John Goerzen complete.org> writes:

All good points. Those are problems that need to be addressed.

Orthogonal to that, there are currently packages that (like
openoffice.org) have a lot of bugs of various ages. Triage seems to be
a good approach to deal with those bugs, and fixes to the problems you
point out will not address those existing old bugs. So complaints
about triage of old bugs seems petulant.

I'm very bad at doing this myself, but it is equally important for bug
submitters to triage their own bugs, especially if they have lots or
many old ones. A ping, some extra info, anything get the bug closer to
being fixed.

--
bye,
pabs

http://wiki.debian.org/PaulWise

"Paul Wise" debian.org> writes:

It's important for bug submitters to *confirm* their own bugs,
especially if newer versions of the package have been released.

That's not the same as *triage*, which is the process of making a
first-run estimate of the priority of each in a set of bugs. I'd say
that is *not* for the bug submitter to do, because bug submitter will
not be able to be sufficiently objective about the bugs they've
submitted.

--
\ "Cross country skiing is great if you live in a small country." |
`\ -- Steven Wright |
_o__) |
Ben Finney

Quoting Paul Wise (pabs@debian.org):

Or also sometimes refrain themselves of filing nitpicking bugs for
corners cases which noone will ever meet. Or when doing this....send
*patches*.

Where resources are low, adding more noise to an already noisy pile of
bugs is just covering dust with more dust.

I don't say that ppl shouldn't file bugs....I more suggest to be a
little bit more selective when filing them.

Of course, this is particularly targeted at jidanni who is very good
for filing bugs as most of us know.

We *are* short on resources and our users should also respect this,
particularly when they *know* that we're short on resources.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

* Christian Perrier debian.org> [080221 08:36]:

Just for the record in case any user is reading this dicussion: This only
holds for packages too large to properly maintain it. For every package
I maintain or might maintain in the future or is small enough that there
are enough people to properly maintain it, please file all bugs you find
that are not already filed. Especially those about corner cases almost
noone runs in. (The obvious bugs I'll find myself eventually,
information about the hard to find ones is the most valueable).

On Wed, 20 Feb 2008, Mike Hommey wrote:

Note that if you look at his archived bugs you have to add:
* 2010 Resolved

Some bugs are of dubious quality, but one must accept that in the end, it's
still impressive. :)

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/