Re: When will emacs 27.1 be officially released?

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: emacs-devel@gnu.org,  liwei.ma@gmail.com
> Date: Wed, 01 Jul 2020 00:09:30 +0200
> 
> > 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?
> 
> It sounds like a vicious cycle; the more we wait for feedback on
> pretests, the more disruptive things happen on master, and the more
> unstability the next release cycle will face…

Changes on master aren't supposed to be disruptive.  And those that
come close are left on master enough time for users to find and report
their problems.

But yes, deciding when to cut a release branch is a tight judgment
call that needs to strike a delicate balance between the two dangers.

> I admit I don't see an easy way out of this situation.  I suspect some
> users (the kind who use Debian Sid, Ubuntu PPAs, or any rolling release
> distro) would flock to "nightly" tarballs and would not get overly
> fussed about incomplete documentation, but that's just a guess.

A decision to disregard our documentation is not mine to take
(although I personally do have an opinion, of course).  It is
something the community as a whole needs to decide, and then we will
have to convince the Powers that Be of the GNU project; good luck with
that!

> >                                                  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.
> 
> I dimly remember that 25.3 sparked some debate regarding the difficulty
> of putting out "targeted bugfix" releases as quickly as we'd like.  I
> don't remember the conclusions; is there anything specific to Emacs that
> prevents us from getting better?

I think it was 26.3, and the problem is not the decision, the problem
was how much time it took.  Too much, IMO.

> > 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.
> 
> "One bug ⇒ one test" is a pretty concrete measure.  Although there are a
> lot of areas in Emacs where writing automated tests is as daunting as
> fixing the bug, if not more…

Adding tests is welcome, but it doesn't help in the issue at hand,
because tests for bugs are added after the bugs are already discovered
and reported.