On 01/10/07 at 16:36 -0400, Joey Hess wrote: > Pierre Habouzit wrote: > > Now that the BTS has versionning, one can use the last version with > > the bug marked as "found" to know if the ping is necessary or not. If > > it's a BTS feature (and not done by the maintainer themselves) that > > would be, say, 2 mails a year (if those are triggered every 6 months > > without activity on the bug), IFF there has been a new upstream (aka > > debian revision uploads assume that if the bug isn't closed the bug is > > still here and the submitter won't get pinged). > > I have 524 open bug reports that I filed in the Debian BTS. What > percentage of these are you suggesting I be pinged for on a yearly > basis? Doesn't this tend to send the message that a bug submitter's time > is less valuable than the package maintainer's time?
Isn't this the case, that in some ways, the submitter's time is less
valuable than the package maintainer's time? Seriously, if we had the bandwidth
to deal with all
open bugs, of course, it would be totally wrong to mass-ping bug
submitters. But it's not the case. For example, in #412176, you said:
Thanks for the patches.
I haven't had a chance to look them over in detail, and there are
some other also uncommitted patches (#412622) that touch the same
part of the code, so it might be a while until I get a time slice
big enough to sort that out.
This was in february, and nothing happened since then. So, clearly,
there's a bandwidth problem.
How do we deal with it? We could decide to mass-close all bugs marked as
moreinfo or unreproducible with no action for more than two months.
This was done in Ubuntu a few weeks ago (see [0] and following emails).
But it's clearly not something we want to do in Debian.
So we have to find a good compromise, and Lior Kaplan's mass-pings seem
to be a good compromise to me. Of course, it's not really nice towards
submitters, so we could have some project-wide directives on how to deal
with those mass-pings, to make them more tolerable. Things such as:
- start with the higher-severity bugs first
- start by only pinging bugs found in a version < version in etch
- include a paragraph explaining why we are doing that
- leave a reasonable period for submitters to comment (2 months seems
enough)
- also ping people who confirmed/could reproduce the bug
This adds complexity, but with the SOAP interface to the BTS, it's easy
to write small scripts to partially automate this.
Also, while *threatening* to close the bug is not really appropriate,
it's better not to lie to the submitters, and tell them that we are
going to close the bugs if they don't answer. Keeping such bugs opened
is a non-sense anyway.
[0]
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-September/001737.html
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
signature.asc
Description: Digital signature
