bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed.

[Eli Zaretskii]

> Date: Mon, 10 Jan 2022 20:21:40 +0000
> Cc: 53164@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@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.  We have
been using the current code for more than a year with no problems
whatsoever.

> > 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.

> 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.

Thanks.