Re: master b082371: Change do-not-merge pattern to "do not merge"

Re: master b082371: Change do-not-merge pattern to "do not merge"

[Glenn Morris]

Paul Eggert wrote:

> branch: master
> commit b08237185ec044c8afff0feb88a126512b33a6d8
> Author: Paul Eggert <eggert@cs.ucla.edu>
> Commit: Paul Eggert <eggert@cs.ucla.edu>
>
>     Change do-not-merge pattern to "do not merge"

Not broad enough. Should also include "don't merge", "no need to merge",
etc. (Unless you think you can get Emacs developers to follow a
convention, which history suggests is unlikely.) This pattern needs to
err on the side of false positives rather than false negatives; and the
person using it needs to think whether to answer yes or no to each
"skip" question. (Nothing here has changed since the bzr days.)

Re: master b082371: Change do-not-merge pattern to "do not merge"

[Paul Eggert]

On 03/22/2016 03:28 PM, Glenn Morris wrote:
> Should also include "don't merge", "no need to merge",
> etc. (Unless you think you can get Emacs developers to follow a
> convention, which history suggests is unlikely.)
I added "no need to merge".  As "don't merge" is typically a false alarm 
(of its six occurrences in the emacs-25 log, five are false alarms), I 
left it out. Let's try to stick with "do not merge" or "no need to 
merge" in future commit messages of this type.

> This pattern needs to
> err on the side of false positives rather than false negatives

Unfortunately it's not that simple. As we've seen, applied false 
positives cause patches to be lost, an error that is unlikely to be 
caught when others review the merge, and some of these errors lurked in 
'master' for over two months. In contrast, applied false negatives cause 
wrong patches to be added, which is much more likely to be caught right 
away on review. So although it makes sense for other reasons to err on 
the side of false negatives, our thumbs shouldn't press too hard on the 
scale.