Re: When will emacs 27.1 be officially released?

[Kévin Le Gouguec]

Thank you for this thoughtful answer.

Eli Zaretskii <eliz@gnu.org> writes:

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

OK.  I'm sure each maintainer has their own ways of prioritizing bugs
and keeping track of those he considers serious; from the POV of curious
users who watch the development process, knowing what's holding the
release is not obvious.

Point (b) taken, though.

>>   (Also can debbugs.el display the "blocked-by" list in a human-readable
>>   format?)
>
> What's wrong with the current display?

Nothing, actually, I hadn't taken the time to check what bindings were
available; now I see that "b" (debbugs-gnu-show-blocked-by-reports) does
exactly what I was looking for (bar hiding resolved issues, but I'm sure
there's a knob somewhere for that).

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

Mmm, I guess in the specific case of documentation, a very naive answer
would be "let's gate pushes to master until commits/branches include the
documentation for the changes they bring".  That would make the master
branch "always release-ready", as far as documentation is concerned.

No idea how to enforce that of course (more on that below).

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

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.

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

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

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

Off the top of my head, I don't have a better answer than "restrict
pushes to master to fully documented commits/branches".  I don't expect
this to make editing manuals and NEWS less time-consuming, but it
*should* help ensure that "things landing on master" does not lead to
"slow buildup of undocumented stuff/obsolete documentation to catch up
with on the release branch".

Of course,

(1) I have no idea how this could possibly be enforced.

(2) Assuming it could be enforced, I'm not sure how well-received the
    idea would be: "drive-by" contributors comply when they are told
    that their changes need manual/NEWS updates, but AFAICT the master
    branch is also used for developers with push access to iterate and
    get some feedback on features they are working on; I'm not sure they
    would get as much visibility if they kept to feature branches…