Re: Next release from master

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex Bennée <alex.bennee@linaro.org>
> Date: Mon, 25 Jan 2016 10:38:23 +0000
> Cc: Barry Fishman <barry@ecubist.org>, emacs-devel@gnu.org
> 
> * master is always the latest greatest
> * as we approach release the criteria to commit to master gets tighter
>   - soft feature freeze, no new features (only features that are "ready" get 
> merged, maybe in stages)
>   - hard feature freeze, any feature for this cycle needs to be in my then
>   - release candidates, bug fixes only
>   - release x.0
>
> Once the x.0 release is done a stable branch is created for future .n
> releases and the metaphorical flood gates opened for features that
> weren't ready for the last cycle can go in.

That's how Emacs development used to work until several years ago.
Since then, we have made the feature freeze period on master much
shorter, and the release branch fork sooner, because there was
considerable pressure from contributors who didn't like the long
freeze.

> Of course the control of this is helped by  the fact we have a lead
> maintainer who merges pull requests from the subsystem maintainers
> (much like the Linux kernel). Very few people have direct commit rights
> to the master repository.

Which of course is anathema in Emacs development.  In fact, I don't
even think it could work in principle for Emacs, because of the number
of distinct areas of expertise which a single individual has no hope
of mastering to be an efficient gatekeeper.

> Would you have people with code that needs to go somewhere during a
> stabilisation cycle? I would hope anything funky just lives on feature
> branches until the next dev cycle opens.

People don't like too many feature branches, even if they are public,
because many times they want more than one feature in their hottest
latest Emacs.