Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] PERFORCE change 78788 by Matthew Clark for review

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] PERFORCE change 78788 by Matthew Clark for review
  • Date: Tue, 2 May 2006 11:48:24 -0500

On May 02, Andra?? ruskie Levstik [ruskie AT mages.ath.cx] wrote:
> > Having the Reply-To: header set is the sanest we can do imho. That way
> > you can easily reply to either the commiter (simple reply), the list
> > (list reply) or both (group reply). Any sane mailer has a list-reply
> > feature, so that works out fine.
>
> Erm yeah.... if you consider mutt sane then I guess any sane...

Some things are features, some things are a matter of interoperability with
the rest of the world.

> I consider etpan-ng and it doesn't have a list reply feature:
>
> - a : reply to the author of the selected message
> - r : reply to the selected messge

One of these is probably meant to use reply-to if it's set and one to
override that? Default 'individual reply' must use reply-to if it's set,
else from. Having an override command makes sense too, I don't know which
is which there. Again, our commit posting daemons set reply-to because
they have to, there's no reason for overriding it on replies to commits.

> - g : reply to all recipient of the selected message

This should use MFT if it's set, else Reply-To(|From)+Cc.

> Only have those...

You can get by with those, not having list-reply mostly means you can't
generate MFT headers that leave you out since you're already on the list,
so you'll possibly get double replies because no one can tell from your
message what your list status is. They can make assumptions (like this
reply, which I'm just sending to the list), but then you put the onus on
them instead of just telling them what you want.

Attachment: pgp7su3SPFR0j.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page