You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Giuseppe Scelsi <gi...@analog.com> on 2006/09/13 06:55:04 UTC
"Precedence: bulk" header in mailer.py
Hi all,
I have just found that notification messages sent by
"/trunk/tools/hook-scripts/mailer/mailer.py" do not have any feature
that lets an out-of-office responder realize they are not to be replied
to. So I added a "Precedence: bulk" header in my copy of mailer.py and
that solved the problem for me (I am using "vacation" under Solaris.)
Before submitting this as a bug report/feature request I wanted to check
if this is the best way to fix this problem. Any comment?
Cheers,
Giuseppe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Karl Fogel <kf...@google.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> 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
*nod* I'll buy that. And the second paragraph describes a better
solution than setting this as a default in mailer.py.
Thanks for taking the time to write it up,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Karl Fogel <kf...@google.com>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> 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
*nod* I'll buy that. And the second paragraph describes a better
solution than setting this as a default in mailer.py.
Thanks for taking the time to write it up,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 9/18/06, Karl Fogel <kf...@google.com> wrote:
> "Justin Erenkrantz" <ju...@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
Re: "Precedence: bulk" header in mailer.py
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 9/18/06, Karl Fogel <kf...@google.com> wrote:
> "Justin Erenkrantz" <ju...@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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Karl Fogel <kf...@google.com>.
"Justin Erenkrantz" <ju...@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...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Karl Fogel <kf...@google.com>.
"Justin Erenkrantz" <ju...@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...)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 9/18/06, Karl Fogel <kf...@google.com> wrote:
> Hmm. Is there some other header that has a more targeted meaning?
> Bulk precedence may have other implications, so if there's a flag that
> just means "no need to auto-reply to this", that would be better. I'm
> not a mail expert, so I don't know if such a flag exists.
Yes, 'Precedence: Bulk' is the de facto standard for this. The SVN
lists all set that flag.
http://www.freebsd.org/cgi/man.cgi?query=vacation&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html
You can also play games with the sender address to trick vacation into
not replying to it. (That might actually be easier in some cases.)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 9/18/06, Karl Fogel <kf...@google.com> wrote:
> Hmm. Is there some other header that has a more targeted meaning?
> Bulk precedence may have other implications, so if there's a flag that
> just means "no need to auto-reply to this", that would be better. I'm
> not a mail expert, so I don't know if such a flag exists.
Yes, 'Precedence: Bulk' is the de facto standard for this. The SVN
lists all set that flag.
http://www.freebsd.org/cgi/man.cgi?query=vacation&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html
You can also play games with the sender address to trick vacation into
not replying to it. (That might actually be easier in some cases.)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Nik Clayton <ni...@ngo.org.uk>.
Karl Fogel wrote:
> Giuseppe Scelsi <gi...@analog.com> writes:
>> I have just found that notification messages sent by
>> "/trunk/tools/hook-scripts/mailer/mailer.py" do not have any feature
>> that lets an out-of-office responder realize they are not to be replied
>> to. So I added a "Precedence: bulk" header in my copy of mailer.py and
>> that solved the problem for me (I am using "vacation" under Solaris.)
>>
>> Before submitting this as a bug report/feature request I wanted to check
>> if this is the best way to fix this problem. Any comment?
>
> Hmm. Is there some other header that has a more targeted meaning?
> Bulk precedence may have other implications, so if there's a flag that
> just means "no need to auto-reply to this", that would be better. I'm
> not a mail expert, so I don't know if such a flag exists.
>
> I've CC'd the dev@ list because this is now a development question
> about mailer.py.
No, 'bulk' is the right one to use in this case. For example, mail from
this list comes with "Precedence: bulk" set so that vacation programs
don't automatically generate replies.
N
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Karl Fogel <kf...@google.com>.
Giuseppe Scelsi <gi...@analog.com> writes:
> I have just found that notification messages sent by
> "/trunk/tools/hook-scripts/mailer/mailer.py" do not have any feature
> that lets an out-of-office responder realize they are not to be replied
> to. So I added a "Precedence: bulk" header in my copy of mailer.py and
> that solved the problem for me (I am using "vacation" under Solaris.)
>
> Before submitting this as a bug report/feature request I wanted to check
> if this is the best way to fix this problem. Any comment?
Hmm. Is there some other header that has a more targeted meaning?
Bulk precedence may have other implications, so if there's a flag that
just means "no need to auto-reply to this", that would be better. I'm
not a mail expert, so I don't know if such a flag exists.
I've CC'd the dev@ list because this is now a development question
about mailer.py.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "Precedence: bulk" header in mailer.py
Posted by Karl Fogel <kf...@google.com>.
Giuseppe Scelsi <gi...@analog.com> writes:
> I have just found that notification messages sent by
> "/trunk/tools/hook-scripts/mailer/mailer.py" do not have any feature
> that lets an out-of-office responder realize they are not to be replied
> to. So I added a "Precedence: bulk" header in my copy of mailer.py and
> that solved the problem for me (I am using "vacation" under Solaris.)
>
> Before submitting this as a bug report/feature request I wanted to check
> if this is the best way to fix this problem. Any comment?
Hmm. Is there some other header that has a more targeted meaning?
Bulk precedence may have other implications, so if there's a flag that
just means "no need to auto-reply to this", that would be better. I'm
not a mail expert, so I don't know if such a flag exists.
I've CC'd the dev@ list because this is now a development question
about mailer.py.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org