Re: Avoiding replies on emacs-diffs

[Karl Fogel <kfogel@red-bean.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>> PS could you reply to emacs-devel rather than emacs-diffs in these cases?
>>>>> (I don't know why emacs-diffs is even configured to accept postings
>>>>> other than from Savannah.)
>>>> Yes, I get bitten by this all the time.  Indeed emacs-diffs should
>>>> refuse such postings.
>>> Adding a header "Mail-Followup-To: emacs-devel@gnu.org" could help.
>> Also: just set the 'Reply-to' header on emacs-diffs@ mails to go to
>> emacs-devel@?
>
>That would suck, just as much as other uses of reply-to: it would make
>it unnecessarily difficult to reply personally to the committer.

Well, it's more complicated than that, I think...

There are two separate but related issues:

  1) The "can't find my way back home" problem, which is why Reply-to
     munging is often objected to when performed on mails people
     actually posted.  We don't have this problem here, though.

  2) The "reader wants to reply to just the author" problem, which is
     related to (1) in that if you can't even find out the author's
     preferred Reply-to address, there's no way you can reply to the
     author.

But that's not the (2) we're talking about here.  Our (2) is simply a
matter of removing the emacs-devel@ address when following up.  Replying
to just the author should be no more difficult than it is now, since the
commit email is already not an email posted by the committer and cannot
be relied on to have an existing Reply-to header with the committer's
preferred email address anyway.

Another way to look at it:

A commit email is an email *from the version control system* to the
maintainer group, announcing a change.  That's why it makes sense for
the maintainer group to be the default forum for replies.  Problem (1)
doesn't apply here at all, and problem (2) doesn't really apply either,
since we already have problem (2) and this doesn't make it worse, and
anyway it's not really a problem because commits are public events to
which public followup (if any) is normally appropriate.

Since most of the time we want discussion of a change to happen among
the maintainer group, having the version control system set that as the
default is reasonable.  (It would be totally different if emacs-diffs@
were a mailing list that humans posted heterogenous messages to
directly, of course.)

This is all based on experience, for what it's worth.  I've worked on
projects that actually do this with their commit emails, and it's been
great.  People seem to like it, and I don't recall hearing any
complaints about it.

-Karl