"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> writes:
> On Mon, Feb 09, 2015 at 12:57:11PM -0800, Junio C Hamano wrote:
>> No, I do not think we have a way to blacklist certain recipient
>> addresses from getting passed to the MTA, and I do not object to
>> addition of such a mechanism if there is a valid need to do so.
>>
>> It feels a bit too convoluted to say "Cc: to this address" in the
>> log message and then "nonono, I do not want to send there", though.
>> Why do you want to have Cc: in the log message if you do not want to
>> send e-mail to that address in the first place? Allowing the
>> behaviour you are asking for would mean that those who see that the
>> commit appeared on a branch would not be able to assume that the
>> patch has already been sent to the stable review address, no?
>
> I could see where it might seem a bit strange. ;-)
>
> The reason behind this is that you are not supposed to actually send
> email to the stable lists until after the patch has been accepted into
> mainline. One way to make this work is of course to leave the stable
> Cc tags out of the commit log, and to manually send an email when the
> commit has been accepted. However, this is subject to human error,
> and more specifically in this case, -my- human error.
>
> Hence the desire to have a Cc that doesn't actually send any email,
> but that is visible in mainline for the benefit of the scripts that
> handle the stable workflow.
So a configuration variable that you can set once and forget, e.g.
[sendemail]
blacklistedRecipients = stable@xxxxxxxxxxxxxxx
would not cut it, as you would _later_ want to send the e-mail once
the commit hits the mainline. Am I reading you correctly?
Or is it that nobody actually sends to stable@xxxxxxxxxxxxxxx address
manually, but some automated process scans new commits that hit the
mainline and the string "Cc: stable@xxxxxxxxxxxxxxx" is used as a cue
for that process to pick them up?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html