GNU bug report logs - #53164
After an ELC+ELN build, don't load the source file into a buffer.

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53164 <at> debbugs.gnu.org
Subject: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed.
Date: Tue, 11 Jan 2022 18:03:14 +0000

Hello, Eli.

On Tue, Jan 11, 2022 at 14:27:14 +0200, Eli Zaretskii wrote:
> > Date: Mon, 10 Jan 2022 20:21:40 +0000
> > Cc: 53164 <at> debbugs.gnu.org, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > After reading this, I still don't understand how come you bump into
> > > this problem, whereas I don't, and neither does anyone else who builds
> > > the release branch with native-compilation.  Is this something
> > > specific to that branch you are working on?

> > Indeed, yes.  It is the symbols with position which escaped from a
> > compiler macro.

> > > If so, why is it urgent to have the fix on the release branch?  The
> > > branch on which you ware working will land on master.

> > There was no urgency.  I though the convention was for documentation
> > fixes and simple safe code fixes to go onto the release branch.  The fix
> > to this bug, a single line, is well understood and certainly comes into
> > the category of simple and safe.

> The fix is well understood, but its possible effects aren't.

OK, we will just have to disagree on this point.  If I wasn't sure about
the lack of possible negative effects, I wouldn't have committed the fix
to the emacs-28 branch.

> We have been using the current code for more than a year with no
> problems whatsoever.

None on the emacs-28 branch, perhaps.  I had severe problems with the
same code on a branch branched from master.  Incidentally, I timed a
bootstrap on the release branch with and without the fix, both starting
from a warm file cache.  With the fix, the build ran ~7% faster.

> > > There's always one more bug.  When we are so far into the pretest
> > > process, problems that take unusual steps to reproduce are not
> > > important enough to delay the release.

> > OK.  But can I ask you to consider announcing on emacs-devel when the
> > criteria for making bug fixes on the release branch change?  Apologies if
> > you have done, and I missed it.

> This is in CONTRIBUTE:

>   If you are fixing a bug that exists in the current release, you should
>   generally commit it to the release branch; it will be merged to the
>   master branch later by the gitmerge function.  However, when the
>   release branch is for Emacs version NN.2 and later, or when it is for
>   Emacs version NN.1 that is in the very last stages of its pretest,
>   that branch is considered to be in a feature freeze: only bug fixes
>   that are "safe" or are fixing major problems should go to the release
>   branch, the rest should be committed to the master branch.  This is so
>   to avoid destabilizing the next Emacs release.  If you are unsure
>   whether your bug fix is "safe" enough for the release branch, ask on
>   the emacs-devel mailing list.

OK, thanks.  I'm not sure I understand any more what "safe" means in
this context.

> > There're three ways we could go.  Commit it in emacs-28, master, or
> > scratch/correct-warning-pos.  I'm willing to commit it again in any of
> > these places.

> Please install this on master (or leave it on your branch), and we
> will revisit this when time comes for Emacs 28.2.

I'll install it on master this evening.  Thanks!

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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