[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 <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.
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.
- 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 <=
- bug#24073: 25.1-rc2, Paul Rankin, 2017/04/01
- bug#24073: 25.1-rc2, Andreas Schwab, 2017/04/01