Re: Bugs against emacsbugs.donarmstrong.com

[Stefan Monnier]

>> You don't know that.
> Of course I know where the most ordinary form of a reply should go:
> the bug, and the person sending the message.
>> Only the person replying knows where that reply should go.
> Enough people replying clearly have no clue where they should go;
> hence this entire thread.
>> Besides, I don't see why getting this result requires fiddling with
>> the reply-to header. Can you give an example?
> To: address@hidden
> From: bar
> Subj: Bug #1234: blah

> Causes the following message to be sent to anyone who should get mail
> involving bug 1234:

> To: address@hidden
> From: bar
> Subj: Bug #1234: blah
> Reply-To: address@hidden, bar

And this is wrong, because if I want to reply only to the author, most
MUAs will force me to copy&paste emails by hand, since a simply "reply
to author" will probably take the address from the "reply-to" rather
than from "From:".

So this header makes "reply to author" behave in the way appropriate for
"reply-to-all", and make "reply-to-all" misbehave (it sends both to
address@hidden and address@hidden, which is somewhat hacked around by Debbugs).

A good header for the email sent by Debbugs would be:

   To: address@hidden
   From: bar
   Subj: Bug #1234: blah

> It'd require changing To: in the above message to some address other
> than the address the message was actually sent to, like address@hidden
> Thus, a bogus value.

That's not a bogus value at all.  It's The Right Thing.
What's the problem with it?

> Debbugs is basically a huge wrapper around a mailing list per bug; the
> issue we have now is that there are multiple aliases for the same
> mailing list, and neither debbugs nor emacs-bugs does message-id
> caching and /dev/null-ing, save on display of messages for debbugs.

If you got the headers right, there wouldn't be much need for such
message-id caching.


        Stefan