bug#24073: 25.1-rc2

[Paul Rankin]

On Sat, 1 Apr 2017, at 09:44 PM, Eli Zaretskii wrote:
> > From: Paul Rankin <hello@paulwrankin.com>
> > Date: Sat, 01 Apr 2017 20:18:37 +1000
> > Cc: Bastien Guerry <bzg@gnu.org>, 24073@debbugs.gnu.org, 
> > mail@nicolasgoaziou.fr,
> >     npostavs@users.sourceforge.net
> > 
> > > > $ git branch -a --contains fe91ff27c54cc10b70a5c5d5bac4017922866717
> > > > * master
> > > >   remotes/origin/HEAD -> origin/master
> > > >   remotes/origin/emacs-25
> > > >   remotes/origin/feature/mhtml-mode
> > > >   remotes/origin/fix-bug-21072
> > > >   remotes/origin/master
> > > >   remotes/origin/scratch/record
> > > >   remotes/origin/scratch/tzz/nettle
> > > 
> > > That's only after emacs-25 has been merged into master.
> > > 
> > 
> > Okay so we've established that the commit is in master after all 👍
> 
> That wasn't controversial to begin with.  The issue was with the
> emacs-25.2-rc2 tag, not with the commit which fixed the bug in
> question.

Question was about this tagged commit in master in Feb after the bug fix commit 
last Sep.

> The commit is on master, whereas the tag was applied to the emacs-25
> branch, which was later merged to master, as part of periodic merges
> we do.
> 
> > Emacs development appears to go along in a kind of unorthodox way.
> 
> It's a merge-based workflow, one of widely used Git workflows.  We
> didn't invent it.  The details are described in the file CONTRIBUTE in
> the tree, under "Branches".
> 
> > As someone familiar with git but unfamiliar with the Emacs dev workflow, my 
> > assumption was that anything in master is ready to ship out the door, with 
> > the bulk of commits happening on feature or hotfix branches. But it appears 
> > to work in the reverse, with everything going into master, and stable 
> > releases branching off, which seems like a good recipe for perpetual 
> > missing-of-boatsness.
> 
> When the branch from which the next official release is about to be
> shipped is close to a release, we don't allow unsafe changes to be
> committed to that branch, because any such change could potentially
> destabilize the entire branch.  There's nothing new here; if you were
> ever involved in releasing very large and complex packages, you should
> be familiar with this paradigm.

Yep, the original question was about workflow, which this answers. Thanks ;)