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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sat, 16 Sep 2017 22:14:57 -0700
> 
>     But not for an emergency release that fixes a security
>     vulnerability: that one must not have any issues or problems
> 
> It is impossible to achieve 100% safety in any realistic release. Even the 
> 25.3 release, which was simple and straightforward, had at least one minor 
> point of confusion in its release announcement that could cause problems for 
> people running older Emacs versions. This was because (as Glenn noted) the 
> announcement gave the wrong version number for when the remote-exploit bug 
> was introduced.

I think there's a misunderstanding of what "100% safe" means in this
context.  It means zero issues beyond those 25.2 had, that's all.
Yes, the glitch with the version number is unfortunate, but it doesn't
affect the code in any way, and even its impact on documentation is
insignificant at worst.  So the goal was reached, for all we know now.

> moving forward, we can do better the next time we have an emergency release. 
> As things stand the process takes too much time, and requires too much manual 
> work, and apparently only one person can actually make a release. These are 
> all things that can be improved on. 

Focusing on how to do better next time is indeed a worthier investment
of our time and energy.  But doing so shouldn't involve repeated
arguments about the details of the 25.3 release -- that is a way of
preparing ourselves for the "previous war".  Next time the details of
the situation will almost certainly be different, and therefore all
the deliberations on what patch should or shouldn't have been part of
25.3 will not help us being better.

Having more people who can upload tarballs to the GNU site is one
obvious improvement.  But it's not enough, as it only accounts for
one-day delay of the 25.3 release.  Other ways to improve our process
are much more important -- and they were not even raised yet, let
alone discussed and decided.  For example:

>     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.)
> 
> As a practical matter, Debian has waaayy more testing than we do. If the 
> patch worked for them that's a strong signal, stronger than any information 
> we have to the contrary.

Maybe so, but Debian testing is limited to Debian systems, and Emacs
is not supposed to work well on Debian alone.  If we want to judge
whether specific changes post the last official release can be
considered safe for inclusion in emergency releases, we need to
identify the sample of GNU/Linux distributions which we could use in
similar decisions, and then have simple and reliable procedures for
finding out how many of these distros use a specific patch from the
Emacs repository, and for how long.  We then need to record these
procedures on one of the files in admin/, so that whoever is in charge
of an emergency release could quickly apply those procedures and make
the decisions.

Would someone want to come up with such a procedure, and provide the
supporting data?

> Among other things if we're just going to do single cherry-picked patches 
> then there seems little point to maintaining the emacs-25 branch any more. 

The emacs-25 branch is not maintained since May.  It stopped being
updated when it became clear that no one is interested in releasing
Emacs 25.3 with a few bugs of 25.2 fixed.  It saw a few commits now as
fallout of this emergency release, that's all, and will fall back into
its limbo from now on.  So I'm not really sure what you are alluding
to here.