bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen 
> <eric@ericabrahamsen.net> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@gnu.org>
>> wrote:
>> >> 
>> >> > And it can go to emacs-26 since it's a doc fix.
>> >> 
>> >> The RC said Emacs 26.2 was to be released March 27...
>> >> Part of making a release is for people to stop changing that
>> branch.
>> >
>> > Unfortunately, that ship has sailed, since within an hour of RC
>> > release a new commit was pushed to the release branch, and another
>> one
>> > a week later, without asking. So now the RC tarball will not be able
>> > to be renamed anyway, and the rationale for withholding doc changes
>> is
>> > null and void.
>> >
>> > "Best laid plans" and all that.
>> 
>> This sounds like a job for a git hook. I pay fairly close attention to
>> emacs.devel for someone who isn't an Emacs dev, and apparently I
>> missed
>> this billboard.
>
> Not sure which billboard jou think you missed, but in general, I don't
> see here any problem for which a commit hook would be a good solution.
> The existing hooks are already annoying enough, and are too easy to
> bypass to be reliable.

What I meant was: if 200 people have the ability to push to the repo,
but 50 of them aren't checking the mailing lists regularly, then you
call a halt to an RC, that's 50 people who don't know they shouldn't
push. It seems like a lot more work to chase after those 50 than to
close the gate and reject pushes to that particular release.