[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24073: 25.1-rc2
From: |
Paul Rankin |
Subject: |
bug#24073: 25.1-rc2 |
Date: |
Sat, 01 Apr 2017 22:05:14 +1000 |
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 ;)
- bug#24073: 25.1-rc2, Paul Rankin, 2017/04/01
- bug#24073: 25.1-rc2, Andreas Schwab, 2017/04/01
- bug#24073: 25.1-rc2, Paul Rankin, 2017/04/01
- bug#24073: 25.1-rc2, Andreas Schwab, 2017/04/01
- bug#24073: 25.1-rc2, Paul Rankin, 2017/04/01
- bug#24073: 25.1-rc2, Andreas Schwab, 2017/04/01
- bug#24073: 25.1-rc2, Paul Rankin, 2017/04/01
- bug#24073: 25.1-rc2, Eli Zaretskii, 2017/04/01
- bug#24073: 25.1-rc2,
Paul Rankin <=
- bug#24073: 25.1-rc2, Andreas Schwab, 2017/04/01