bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24073: 25.1-rc2


From: Eli Zaretskii
Subject: bug#24073: 25.1-rc2
Date: Sat, 01 Apr 2017 14:44:31 +0300

> From: Paul Rankin <address@hidden>
> Date: Sat, 01 Apr 2017 20:18:37 +1000
> Cc: Bastien Guerry <address@hidden>, address@hidden, address@hidden,
>       address@hidden
> 
> > > $ 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.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]