Re: When will emacs 27.1 be officially released?

[Eli Zaretskii <eliz@gnu.org>]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: emacs-devel@gnu.org, Liwei Ma <liwei.ma@gmail.com>
> Date: Tue, 30 Jun 2020 11:51:59 +0200
> 
> More seriously though.
> 
> - Does bug#39200 come anywhere close to an exhaustive list of issues to
>   address before the 27 branch is considered stable?

I tend to treat these "blocking" bug reports as advisory only.  E.g.,
the bugs you see there now (a) don't sound too serious to me, and
(b) don't seem to cause anyone to go out of their way fixing them.

So if you think this is what prevents us from releasing Emacs 27.1,
it's not.

>   (Also can debbugs.el display the "blocked-by" list in a human-readable
>   format?)

What's wrong with the current display?

> As a user, I think I'd find it acceptable to have a slightly less stable
> x.1 if I had the promise of more frequent x.(n+1) releases (bugfixes).

The main problem is how to translate "slightly less stable" and "more
frequent" into actionable procedures that we can support given the
resources.  We all agree with these principles (well, at least I do),
but Life™ is more complex than we'd like it to be.  See below.

> See e.g. how many people use MELPA (live untagged commits from master)
> vs. MELPA stable (only tagged versions): it seems to me that there are
> some people out there who are comfortable living on the /bleeding/ edge,
> with all the occasional discomfort that entails.

MELPA is a collection of Lisp packages.  Lisp packages seldom cause
catastrophic problems in a running session, like crashes, loss of
edits, etc.  Our job is more complex and the dangers from releasing a
less-than-stable Emacs are higher.  That's one reason why we cannot
follow that example.

Another reason is that each MELPA package is quite small and simple,
certainly in comparison with Emacs.  So the time and effort needed for
the maintainer to put out a new version are much smaller than what we
need.  Even the most mundane aspect of an Emacs release, such as
update of the documentation and NEWS, takes orders of magnitude more
time for us than it takes for an elpa package.  Would you agree to
release Emacs with incorrect/inaccurate/outdated manuals?

> If we assume x.1 releases will have more exposure than x.0.z (pre-tests,
> RCs) by virtue of being packaged by distros, it could help bring issues
> to our attention faster, which means regressions could be easier to fix
> because we wouldn't have doubled down on problematic design choices
> (this is a very abstract observation, I don't have a concrete example of
> a recent "problematic design choice" hindering a bugfix).

See, that's another factor that people tend to forget or ignore: it
takes a long time for Emacs problems to be discovered and reported.  A
new Emacs release can take years to reach end users.  We are routinely
receiving bug reports about changes made two or more releases ago.  If
you are looking for a single most important reason why it takes so
long to put out another pretest, it is this one: experience shows that
it takes weeks if not months for enough people to try a pretest and
report the problems they see.  Once a problem is reported, it is
usually fixed very quickly, but how do you know the important problems
were all discovered, except by waiting?

> And it's not like distros packaging "broken" x.1 releases will break
> every user's workflow.

That's true, but Emacs has a reputation of being very stable, even for
the development snapshots.  Breaking the workflow of even a single
user causes that user grief and is not welcome.  Especially since an
emergency bugfix release is also not something we can do quickly
enough, as one or two occurrences in the past have shown.

> Take gcc on Ubuntu for example: the default "gcc" package on 20.04
> is 9.3, but adventurous users can already try out version 10 by
> installing "gcc-10", thereby opting in explicitly and deliberately
> for new features, and potential breakage.

I don't think you can compare breakage of a compiler with breakage of
Emacs.  A broken compiler can fail to build a program, which is not a
catastrophe; losing several hours of editing can well be a
catastrophe.

So once again, the practical issue here is what to do differently to
make the releases more frequent, without losing too much of stability
and other good qualities.  I mean practical measures, not general
considerations with which everyone will agree.  E.g., let's start with
a small step: how do we make the effort of preparing the manuals and
NEWS for a release less time-consuming?