Re: Branch freezing for release (WAS: bug#34776)

[Eli Zaretskii]

On April 10, 2019 11:57:09 AM GMT+03:00, Noam Postavsky <address@hidden> wrote:
> >>>>>> 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

We don't have access to the server, so doing this would be a significant 
complication, even if we ignore the annoyance of a rejected commit and a 
potential for failing to push if one doesn't watch the messages closely enough 
(actually happened to me at least once).

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

There's no need to say anything else, since an RC should be tarred after all 
its changes are pushed and tagged.  That didn't happen this time by omission.  
We all make mistakes at times.