emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When will emacs 27.1 be officially released?


From: Kévin Le Gouguec
Subject: Re: When will emacs 27.1 be officially released?
Date: Tue, 30 Jun 2020 11:51:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> Indeed, I think the development team should be fired, starting from
> the head maintainer, who is clearly incompetent.  They cannot even
> make a simple release on time.

This.  I mean, Emacs's roadmap is pretty well-defined; the user stories
are scheduled very precisely, and the develop^Wvalidation team does a
stellar job at finding regressions before features are integrated into
the mainline.  Now if only maintainers would do their job instead of
drowsing off…


More seriously though.

- Does bug#39200 come anywhere close to an exhaustive list of issues to
  address before the 27 branch is considered stable?

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

- I dimly remember a discussion on bug-gnu-emacs between Eli and Dmitry
  a couple of months back, about how thorough the team should be about
  fixing regressions before releasing x.1.  My 2¢:

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

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.

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

And it's not like distros packaging "broken" x.1 releases will break
every user's workflow.  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 hope this doesn't come across as armchair commentary; apologies if it
does.

And many thanks to "the development team" :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]