Re: Branch freezing for release

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Apr 2019 09:14:06 -0400
> 
> FWIW, that's part of the reason why I suggested that we make
> a emacs-26.2 branch once we start entering the phase where we should not
> push any change unless explicitly allowed by the maintainer.  This way
> people can keep pushing random bug fixes to emacs-26, unaware that
> an emacs-26.2 was created.

Unless the hypothetical emacs-26.2 branch is local, why would people
be unaware of its creation?  Git happily announces its creation and
each of its updates on every fetch/pull.

> It's also useful for bug fixes which we'd want to have in a hypothetical
> 26.3, so they don't get lost in master.  It makes the rules simple:
> 
> - master:      always open for business.
> - emacs-NN:    bug-fixes only (merged back to master every once in a while)
> - emacs-NN.MM: never touch unless specifically authorized to do so.

I don't see this as a simplification, I see this as a complication:
one more branch to track, to describe in CONTRIBUTE, to educate people
about, to avoid mixing with others, etc.

> Look ma!  No need to follow emacs-devel to know in which phase we are!

There's no need to follow emacs-devel now, either.  The rules are laid
out in CONTRIBUTE, and once each RC will have its modifications pushed
and tagged, the problem which led to this particular bikeshedding
should not happen again.  IOW, this is a normal process of learning
how to release Emacs cleanly.