bug#5789: bug-coreutils debbugs reply message refers to bug-gnu-emacs

[Glenn Morris]

reassign 5789 debbugs.gnu.org
retitle 5789 there is a single mailing list for control messages
severity 5789 minor
stop

Bob Proulx wrote:

>> The debbugs automated reply message in response to opening a new bug
>> still refers to address@hidden

They refer to help-debbugs at gnu.org now, which is where this bug
report should end up going now that I have reassigned it...

> Additionally I see that the debbugs trace messages noting bug status
> processing also references the emacs-bug-tracker.
>
>> From: GNU bug Tracking System <address@hidden>
>> To: Bob Proulx <address@hidden>
>> Cc: address@hidden
>> Subject: Processed: closing bug

(The From: address should be help-debbugs now.)

Yes, I did try and explain that this was going to happen.
We have patched debbugs so that there is a single control list which

i) gets copies of the automated mails that the tracker sends out in
response to control messages (tagging bugs, etc).

ii) when you send a mail to 123-done, this generates a "bug closed"
messages that goes to the submitter and the control list.
The normal maintainer list gets a slightly different version of the
message that you sent, in exactly the same way as if you had sent a
message to 123 (without the -done) part. It has a Mail-Followup-To
header set to the 123 address without the done part, so that any
further replies do not end up accidentally closing the bug again.

We did this because we did not want all the (boring) control messages
cluttering up the bug-gnu-emacs list.

The control list is

http://lists.gnu.org/mailman/listinfo/emacs-bug-tracker

With hindsight, the name would be better off as being more general
("debbugs-tracker"), but it is a little late to change it now.

I can easily change the "Cc:" header you quote above to have any
content, but the actual messages themselves will still get sent to the
emacs-bug-tracker list.

Debbugs expects there to be a single address to receive control and
bug-done messages. One could imagine changing this so that where
things end up depends on the package a bug is in, but I think this
would be

a) difficult (since a single control message can refer to multiple
packages, and even a single bug can be in multiple packages)

b) not very important, since the control messages are pretty boring
(which is why we farmed them out to a separate list), and probably not
numerous enough to merit a separate list for each package.

So trying to change this is not something that interests me personally
very much.