[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "Precedence: bulk" header in mailer.py

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2006-09-18 19:18:00 CEST

On 9/18/06, Karl Fogel <kfogel@google.com> wrote:
> "Justin Erenkrantz" <justin@erenkrantz.com> writes:
> > However, I wouldn't want our mailer to set this flag unconditionally -
> > i.e. needs to be opt-in to set this flag as some cases would want to
> > trigger those notices. -- justin
> Hmmm, I'm having trouble thinking up such a case. Do you know of any
> examples?
> (I'm beginning to think bulk might be a reasonable default after all...)

For example, I'm telling it to send the commit as me and it's
configured to send the commit emails to myself and a bunch of
colleagues. One of those colleagues (call him John) is on vacation
and set up vacation. Now, if 'vacation' has already informed me that
John is away, it won't notify me again. However, if 'vacation' hasn't
done that yet, it'll send me an email that John is gone. That's good.
 I now know that John won't be reviewing my commit. This is ideal for
small groups which don't justify the overhead of a mailing list.

Now, if you really want bulk precedence, you should just set up a list
and point the mailer at it - most list managers will add the
precedence header by default. But, if you send it to a bunch of
people directly (sans list), the intention (to me) is that you want to
know if they won't read that commit message. In either of those
'normal' cases, mailer shouldn't add the header. Note that some
mailing lists are configured to reject emails if the Precedence: Bulk
header is already set in an attempt to limit spam - so doing so might
cause those commits to be rejected. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 19:18:20 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.