gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/17/20 12:59 PM, Iain Sandoe wrote:
> Joel Brobecker <brobecker@adacore.com> wrote:
> 
>>>>> AFAIU, we have access to more fine-grained information; isn’t it possible
>>>>> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
>>>>> (because a ‘new’ commit does not have the extra fields set up for merges
>>>>>  and rebases).
>>>>
>>>> In my opinion, this would create a lot of complication for the benefits
>>>> being gained. I also think that the more variations of behaviors you
>>>> introduce, the harder is becomes for people to know what's right and
>>>> what's not expected.  People then start getting surprised and start
>>>> asking about it. At best, it's just a quick answer, but in some cases,
>>>> it takes time to remember why we set things up the way they are and why
>>>> it doesn't make sense to change it. Over the years, I have really 
>>>> learnt
>>>> to enjoy the benefits of consistency, even if it is means some areas
>>>> are suboptimal. The "suboptimality" can still be a better compromise
>>>> overall than a superengineered system.
>>>
>>> Spamming the list with emails every time someone merges master to their
>>> development branch sounds highly suboptimal, and likely to lead to disabling
>>> email entirely for those branches.  Is it so complicated to send a single
>>> email for a merge commit or non-fast-forward push?
>>
>> Well, no. I was going so say that this is what I have been proposing
>> all along, except the way you phrased your suggestion above makes
>> me think that perhaps you want something more automatic, where the hooks
>> decide dynamically, rather than the choice being made by configuration.
>> So it's not exactly the same, but quite similar in spirit.  I think
>> we can find ways that will satisfy the need for fewer emails without
>> having to have that extra logic, though.
>>
>> Also, you guys have to understand that you are all coming to me from
>> multiple directions at the same time, and making requests that are
>> not always easy to reconcile. I do completely understand that getting
>> hundreds of emails because of a merge into a development branch is far
>> from optimal, and it's absolutely not what I am suggesting we do here.
>> In fact, you'll see that I told Joseph in a separate mail that I will
>> think this over and try to come up with something that answers the
>> situation he described. What I am alerting people to is trying to
>> have special-case handling for every scenario we can conceive.
> 
> for my part, I was not trying to specify “requirements” - but identify different
> scenarios that we might want to handle (better to decide how we want to do
> things at the start, than to create changes later).

Indeed, this is largely a discussion about what is desirable and 
feasible.  How straightforward a particular request will be is helpful 
feedback.  Thank you, and sorry I got snarky above.

Jason