Re: Do pretests reach end users?

[Dmitry Alexandrov]

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.

signature.asc
Description: PGP signature