On Wed, Oct 03, 2007 at 01:49:47AM -0400, Eric Dorland wrote: > * Juliusz Chroboczek ([EMAIL PROTECTED]) 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 > bugs. > > 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 devscripts. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]