Re: Why wasn't the 25.3 release based on the then-head of the emacs-25 branch?

[Eli Zaretskii]

> From: Glenn Morris <address@hidden>
> Cc: address@hidden
> Date: Fri, 15 Sep 2017 19:39:08 -0400
> 
> Eli Zaretskii wrote:
> 
> > The emacs-25 branch included a couple of non-trivial code changes post
> > 25.2, which were not widely tested.  In fact, I'm guessing that no one
> > actually used the branch, once 25.2 was released, more than just start
> > it up and maybe run the tests. 
> 
> I'm not aware of any non-trival code changes.

Then I guess we have different notions of "trivial".

> For the record, the _only_ code change (until Paul's gcc-7 changes last
> Friday, which do seem trivial)

No, heyt aren't.  They affect the build process, so could potentially
break the build on some systems.

> in the emacs-25 branch was the tls one I referred to. It had been
> present in both emacs-25 and master since April, as well as being
> distro-patched by Debian in their Emacs 25.1 package over the same
> time period (since they considered it a serious issue, ie one that
> otherwise merits eventual removal of the affected package; ref
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766397 ).
> Personally I consider that ample testing.

Even if the Debian distro could be considered ample testing (and I'm
not sure it could, as Debian AFAIR are generally not on the bleeding
edge with system features, library and kernel versions, etc.), there
wasn't enough time to perform the research which could convince us
that change was tested well enough for us to trust it.  In fact, there
wasn't even time to find out whether any distributions patched their
Emacsen with that change.  What little time we had was used to come up
with a reasonable patch for the problem and thoroughly test it.

Another factor that affected my decision was that when we discussed
the possible release of 25.3 back in May, no one felt this tls patch
was serious enough (to say nothing of the memory-allocation problems)
to require another bugfix release.  How come it's suddenly so
important that we were supposed to risk producing a less-than-perfect
tarball just to have it?

In general, we never released any code that was not tested via the
normal pretest/RC cycle that we are familiar with.  You are talking
about a procedure that was never used by this project, for as long as
I remember it.  I don't think it would have been prudent for us to
invent a new procedure while producing an urgent release that was
intended to plug a security vulnerability, and use it the first time
for that urgent release.  How many times did you see a new procedure
we tried here that succeeded the first time it was used?  I never saw
anything like that.

This release needed to be 100% safe.  Not 99.99%, 100%.  IME, this
calls for qualitatively different mindset and measures than the usual
process, where small risks for unlikely events are acceptable if the
gains justify them.  100% safe meant we could not tolerate _any_
risks.