Branch freezing for release (WAS: bug#34776)

[Noam Postavsky]

>>>>>> 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 [...]

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

Git supports server-side hooks which can't be bypassed.  If I read
githooks(5) correctly, then putting an update hook on the server with
contents:

    if [ "$1" = emacs-26 ]; then
       echo "Branch $1 is frozen"
       exit 1
    fi

would do it.  There would still be some additional complication with
letting in the commit for the RC itself though.  Andreas' suggestion to
just let unexpected commits miss being in the release seems simpler.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34776#61

>> 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.
>
> There's no need to check the mailing list, this stuff is in
> CONTRIBUTE.  That's why I never called for any halts.

CONTRIBUTE says:

    Doc fixes are always considered "safe" -- even when a release branch is
    in feature freeze, it can still receive doc fixes.

I don't see anything there about not pushing after an RC is made (and
how would someone know about the RC without checking the mailing list?)