Re: Do pretests reach end users?

[Dmitry Alexandrov <dag@gnui.org>]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

Eli Zaretskii <eliz@gnu.org> wrote:
> Dmitry Alexandrov <dag@gnui.org> wrote:
>> Emacs pretest release?  Is that a thing for systems other than Microsoft Windows and Guix?
>
> I didn't say "pretest release": there's no such thing.  A pretest is not a "release"

Okay.  (Though to me ‘pretest’ still looks like an adjective there.)

> it's a tarball [with sources]

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/emacs-27.0.91-x86_64-installer.exe

> meant to be tested by people who track the Emacs development.

I believe, people who track Emacs development rather build from master.

> Its difference from the corresponding Git branch is that it is a tarball that builds like a release would, and thus one of its main purposes is to see that the tarball itself doesn't miss anything (which would mean we need to fix our procedure for producing the tarball).

Aha.  Thanks for explanation.

Yet, I suppose, only a neglectable minority of bugs can be introduced by release procedure itself.

> And the other important purpose is to catch the attention of people here and encourage them to switch to the pretest version instead of the Git version

That is, it exists to encourage those who track the master branch to downgrade?  o_O

> IME, changes to the Git repository also take several weeks to generate reports about problems.

Well, for me thatʼs easily understandable: I normally use Emacs master, but rebuild it only when its time to restart it for out-of-band reasons, which indeed happens once in a week or even couple of weeks.  I suppose, I am not unique here.


>>  Unstable Debian comes with Emacs 26, Ubuntu gets Emacs from Debian.   Arch comes with version 26, AURʼs ‘emacs27’ is 27.0.60 — an outdated February snapshot [1].   Unstable Nix, again, contain 26th Emacs.   Fedora provides only stable version of Emacs.   Homebrew — guess what?

> We cannot control the policies of the various distros

Of course, you can!

Just declare the next pretest version 27.1 instead — and youʼll see dozens of various distros from unstable Debian to Termux (a distribution of terminal applications for Android-like OSes) obediently picking it up.

Current stable Debian will never pick it up, of course, so its users are safe from any new bugs and features, and testing Debian — only after running it in for a few weeks in unstable.

> and [we] cannot rely on them for being part of the pretest.

Indeed, _now_ you can not.  That looks like a problem to me.

> Sometimes they are, nonetheless, presumably because the people who are responsible for the distros read the announcements about the pretests

Any example?

With your clarification about what pretests are, I have to withdraw Guix from the list of systems where they are available — its ‘emacs-next’ is built from Git.  That is, the _only_ known to me system left, where Emacs pretests are available for installation, is Microsoft Windows.

> But it isn't the main means for pretesting.

Sure.  From all of the above we can surmise that main pretesters are Windows users, who somehow learn (from Reddit-like resources?) about pretests and download them from gnu.org.

Well...  Windows is the most popular desktop system after all, but I would really like to see GNU Emacs better tested on secondary platforms, such as GNU/Linux, too.


And I see two ways to achieve it.

The first one is to contact all distributors one by one, explaining them that they better be reading announcements for Emacs pretests in order to package them in their unstable branches, as Emacs pretest is actually pretty stable for todayʼs standards of development.

If anyone would like to do that, I have a suggestion, where to start from — nixpkg-unstable:

| Maintainers:
|    Jason O'Conal <jason@oconal.id.au>,
|    Peter Simons <simons@cryp.to>,
|    John Wiegley <johnw@newartisans.com>,   <----
|    Adam Hose <adis@blad.is>
— https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=emacs

;-)

And the second one is already mentioned  — just declare what would be a pretest a release.

> Severe problems, like crashes upon startup, are, of course reported much faster, but a pretest version is always quite stable and devoid of such problems.
>
> So I don't see how all this could help making a release faster.

It can help persuade people in charge (such as you :-) to take advantage of the control over GNU distributors they have — and shorten the release cycle.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]