Re: the new style "mass tirage" of bugs
On Thu February 21 2008 12:51:42 am Ben Finney wrote:
> "Paul Wise" <pabs@debian.org> writes:
> > 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.
>
> It's important for bug submitters to *confirm* their own bugs,
> especially if newer versions of the package have been released.
Yes, I agree. But I find myself on both sides of this fence.
When people submit bugs on Bacula that are upstream bugs, I rarely want to
try to hack into it myself. I view backup software as something akin to
fsck: something I don't want to fsck with unless I really have to, because
it's so important.
Sometimes a changelog entry upstream sounds like it's fixed a bug, or the bug
has been open long enough that some major relevant piece of architecture has
changed, and I want confirmation that it still exists before harassing
upstream about it.
On the other hand, as a user, I may be running etch on a production server
and have no means to validate whether some change in sid or lenny actually
fixes things.
Here's the thing. If bugs I submit actually get looked at by a human, and
humans are fixing a reasonable percentage of bugs submitted, I don't mind
testing things out on new versions whenever I can.
But if there's a blackhole where all I *ever* hear about a particular bug --
or even any bug on that package -- is the periodic "does it still exist?",
well that is a really poor way to treat users.
Ignoring bug reports and then using "triage" as a way to close them after new
releases is an abuse of the BTS.
-- John
Reply to: