Re: Does anyone have a script to query users about bugs they submitted ?
Thomas Viehmann <firstname.lastname@example.org> schrieb:
> Jean-Michel Kelbert wrote:
>> I am looking for a script to send a mail to all users who submitted a
>> bug to my packages to ask them if the bug is already present. As a
>> matter of fact this script should send the mail under certains
>> circonstances for example :
> IMO, sending automated mails to the BTS is a bad habit altogether.
> If you expect users to take the time to report bugs, you probably should
> take the time to answer and follow up to them.
> I think that the BTS and maintainer responsiveness has been part of what
> makes the Debian user experience positive and automated responses
> "please all submitters of bugs to me do foo" will harm that.
I second that, having some experience with bug-cleanup: When I entered
the teTeX maintainers team last summer, there were lots of bugs that had
somehow slipped through, been forgotten, neglected, etc.¹, and it was
(and is) a hard task to get back to original submitters and start
But I am sure that automated mails would not have worked, and would also
not work if we had waited for the new upstream version to enter
Debian. Some reasons for that:
- old submitter mail addresses bounce - you have to look a the bug, dig
out the submitters real name and, if possible, more information about
the person, and fire up google.
- submitters don't always use unstable; it doesn't make sense to simply
ask "is the bug still there"
- submitters didn't properly describe what was wrong, so they have no
way of testing whether it is still wrong. You first have to talk to
them and ask what they expected to happen, what really happened, and
how they tried, or usually try if they don't remember
- it's much better to get involved with two or three of your packages'
prehistoric bugs and properly work on those, instead of trying to do
everything at a time. In the best case you get lots of answers, and
then you seem unresponsive again, because you are not able to properly
follow up on that within a couple of days, especially when this
following-up means that you have to read documentation, find out who's
responsible upstream for a particular module of the software, read
through archives and initiate a contact before you can get back to the
¹simply because the team was too small, I guess
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie