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

[Eli Zaretskii]

> Date: Tue, 11 Jan 2022 18:03:14 +0000
> Cc: 53164@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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 are mis-communicating.  I didn't mean something as silly as saying
that the result of removing a command-line argument is not well
understood.  What I meant to say is that since it's impossible to look
at all the possible situations where this code is being used, we
cannot know what would happen due to this removal.  You basically only
tested the fix in one situation, where you discovered the problem, and
just assume that it cannot possibly have any adverse effects on the
infinity of other cases.  But that's just an assumption.

The reason we have long pretests is precisely because code we think we
understand has unintended consequences that take a lot of time to
reveal.  This change is no different.

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

Thanks, but at this point in the pretest I no longer worry about
speeding up the build.

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

That's right, at this point no change is "safe" a-priori.

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