On Thu February 21 2008 12:51:42 am Ben Finney wrote: > "Paul Wise" <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]