Re: Firefox bugs mass-closed.
On Wed, Oct 03, 2007 at 01:49:47AM -0400, Eric Dorland wrote:
> * Juliusz Chroboczek (firstname.lastname@example.org) wrote:
> > > Also node that many bugs are sometimes hard to reproduce, because you
> > > need a very specific environment that the maintainer not always have
> > > (e.g. the issue I have is that as a glibc maintainer, I've no large
> > > enough and used pam-ldap or NIS setups, and we have some bugs that rot
> > > because I don't have either the time or the resource to test them
> > > properly).
> > I have no problem with the maintainer (a human being) asking me to do
> > something sensible about my bug report, such as confirming that the
> > bug still happens with the version in experimental, testing on a setup
> > he doesn't have access to, producing a backtrace, running random
> > commands on my system (as long as I understand what they do) etc.
> > What Joey and I are specifically complaining about are three bugs that
> > we have described in enough detail and that are trivial to reproduce.
> > The maintainer did not send us personal mail asking for help; he sent
> > us an automated mass mailing threatening to discard our perfectly
> > valid reports unless we take some arbitrary action.
> > This is clearly not the case that you are describing.
> So it isn't the maintainers who are doing this, but Lior. He asked if
> he could help and of course we said yes. I didn't vet (nor do I
> believe Mike did) the messages he sent out, nor do I really think we
> should have.
> Now that I've done some blame deflection, I really appreciate Lior
> work but I agree that narrowing the search criteria would make this a
> bit less spammy. Let me try to summarize some of the constructive
> ideas brought up in the thread.
> + Bugs marked unreproducible and lacking response from the submitter
> should very likely be closed.
> + Bugs with severity < normal, bugs forwarded upstream and bugs marked
> confirmed should probably not receive emails or perhaps just helpful
> reminders of its existence if the bug is older than X.
> + Better metrics should be come up with based on age of the bug, most
> recent "found" version and last activity on the bug. Not sure exactly
> what numbers to plug in, bug those seem like good indicators of
> continued relevance.
> + Maybe only sending a single email to a submitter with multiple open
> I think with some improvements like this there would reduce the false
> positive rate a lot. While it would be great to treat every bug
> individually by a human, the amount of bugs is really unmanageable and
> hugely time consuming by the small group of maintainers. These sort
> of automated reminders are a big help, even if they're not perfect yet.
It could be worth writing a script dealing with this, especially
now the BTS has "activity reporting" for bugs, that could land in