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

[Iain Sandoe]

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).

As a general rule, I’m 100% in favour of KISS.

> I'm wondering if we wouldn't be better off having this discussion live
> over a meeting or a series of meetings…

could be,

Iain