GNU bug report logs - #24073
24.5; outline-on-heading-p sees any invisible text property as outline inviisble

Previous Next

Full log

Message #122 received at 24073 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Rankin <hello <at> paulwrankin.com>
Cc: bzg <at> gnu.org, 24073 <at> debbugs.gnu.org, schwab <at> linux-m68k.org,
 mail <at> nicolasgoaziou.fr, npostavs <at> users.sourceforge.net
Subject: Re: bug#24073: 25.1-rc2
Date: Sat, 01 Apr 2017 14:44:31 +0300

> From: Paul Rankin <hello <at> paulwrankin.com>
> Date: Sat, 01 Apr 2017 20:18:37 +1000
> Cc: Bastien Guerry <bzg <at> gnu.org>, 24073 <at> debbugs.gnu.org, mail <at> nicolasgoaziou.fr,
> 	npostavs <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.