Emacs 28.2 released

Emacs 28.2 released

[Stefan Kangas]

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

Version 28.2 of Emacs, the extensible text editor, should now
be available from your nearest GNU mirror:

   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.xz
   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.gz

The tarball is signed; you can get the PGP signature file at:

   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.xz.sig
   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.gz.sig

You can choose a mirror explicitly from the list at:
  https://www.gnu.org/prep/ftp.html

Mirrors may take some time to update; the main GNU FTP server is at:
  https://ftp.gnu.org/gnu/emacs/

To verify that the downloaded tarball is intact, download both the
tarball and the corresponding .sig file, and run this command:

  gpg --verify emacs-28.2.tar.xz.sig

(and similarly for emacs-28.2.tar.gz, if you download that format).

If the GPG command fails because you don't have the required PGP
public key, run this command to import the key:

  gpg --keyserver pgp.mit.edu --recv-keys \
    CEA1DE21AB108493CC9C65742E82323B8F4353EE

Alternative keyservers to try are keyserver.ubuntu.com and keys.openpgp.org.

You can also run sha1sum or sha256sum and confirm that these
checksums match:

SHA1  emacs-28.2.tar.xz
d61863db02b732547e6d6c77081e3348734458be
SHA1 emacs-28.2.tar.gz
b019ec832c73cd8548981fe2bc11a7d6e812ddb9

SHA256  emacs-28.2.tar.xz
ee21182233ef3232dc97b486af2d86e14042dbb65bbc535df562c3a858232488
SHA256 emacs-28.2.tar.gz
a6912b14ef4abb1edab7f88191bfd61c3edd7085e084de960a4f86485cb7cad8

Emacs 28.2 is a bug-fix release, with no new features with respect to
Emacs 28.1.

For the complete list of changes and the people who made them, see the
various ChangeLog files in the source distribution.  For a summary of
all the people who have contributed to Emacs, see the etc/AUTHORS file.

The online manuals and website will be updated shortly.

Printed copies of the Emacs manual are available for purchase from the
Free Software Foundation's online store at:
  https://shop.fsf.org/product/emacs-manual/

For more information about Emacs, see:
  https://www.gnu.org/software/emacs

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

Re: Emacs 28.2 released

[Michael Albinus]

Stefan Kangas <stefankangas@gmail.com> writes:

> Version 28.2 of Emacs, the extensible text editor, should now
> be available from your nearest GNU mirror:

Great, thanks a lot!

Does it mean that the emacs-28 branch is reopened for patches? I have
some of them hanging around in Tramp's 2.5 branch.

Or is it unlikely that there will be an Emacs 28.3?

Best regards, Michael.

Re: Emacs 28.2 released

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Stefan,

> Does it mean that the emacs-28 branch is reopened for patches? I have
> some of them hanging around in Tramp's 2.5 branch.
>
> Or is it unlikely that there will be an Emacs 28.3?

Forget the message. I've just seen your latest changes in the emacs-28
branch, this answers my questions.

Best regards, Michael.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Sep 2022 13:28:33 +0200
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > Version 28.2 of Emacs, the extensible text editor, should now
> > be available from your nearest GNU mirror:
> 
> Great, thanks a lot!
> 
> Does it mean that the emacs-28 branch is reopened for patches?

Yes.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Sep 2022 13:28:33 +0200
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > Version 28.2 of Emacs, the extensible text editor, should now
> > be available from your nearest GNU mirror:
> 
> Great, thanks a lot!
> 
> Does it mean that the emacs-28 branch is reopened for patches?

Yes.  But please, only safe ones.

> Or is it unlikely that there will be an Emacs 28.3?

Too early to say.

Re: Emacs 28.2 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Does it mean that the emacs-28 branch is reopened for patches?
>
> Yes.  But please, only safe ones.

Sure. No new features, only what Tramp has released already via GNU ELPPA.

Best regards, Michael.

Re: Emacs 28.2 released

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Or is it unlikely that there will be an Emacs 28.3?

If there are serious bugs in Emacs 28.2, then there'll be another
release.  But as things stand now, I'd rather the next release be Emacs
29.1.

Re: Emacs 28.2 released

[Karl Fogel]

Congratulations on the release!

Since these release announcement emails are widely shared (I saw 
this one appear on news.ycombinator.com, for example), it might be 
good to include a link to corresponding release notes.

That could be a link to an appropriate named anchor on 
https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases 
(but there do not appear to be release-specific anchors on that 
page currently, so we'd have to add that to release process).

Or it could be a link directly to the plaintext release notes that 
the above web page points to anyway; in this case, that would be 
https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.28.1.

Either way, it would be helpful to those who see these release 
announcements to be able to go directly from the announcement to a 
page that tells them what's new in that release.

Best regards,
-Karl

On 12 Sep 2022, Stefan Kangas wrote:
>Version 28.2 of Emacs, the extensible text editor, should now
>be available from your nearest GNU mirror:
>
>   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.xz
>   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.gz
>
>The tarball is signed; you can get the PGP signature file at:
>
>   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.xz.sig
>   https://ftpmirror.gnu.org/emacs/emacs-28.2.tar.gz.sig
>
>You can choose a mirror explicitly from the list at:
>  https://www.gnu.org/prep/ftp.html
>
>Mirrors may take some time to update; the main GNU FTP server is 
>at:
>  https://ftp.gnu.org/gnu/emacs/
>
>To verify that the downloaded tarball is intact, download both 
>the
>tarball and the corresponding .sig file, and run this command:
>
>  gpg --verify emacs-28.2.tar.xz.sig
>
>(and similarly for emacs-28.2.tar.gz, if you download that 
>format).
>
>If the GPG command fails because you don't have the required PGP
>public key, run this command to import the key:
>
>  gpg --keyserver pgp.mit.edu --recv-keys \
>    CEA1DE21AB108493CC9C65742E82323B8F4353EE
>
>Alternative keyservers to try are keyserver.ubuntu.com and 
>keys.openpgp.org.
>
>You can also run sha1sum or sha256sum and confirm that these
>checksums match:
>
>SHA1  emacs-28.2.tar.xz
>d61863db02b732547e6d6c77081e3348734458be
>SHA1 emacs-28.2.tar.gz
>b019ec832c73cd8548981fe2bc11a7d6e812ddb9
>
>SHA256  emacs-28.2.tar.xz
>ee21182233ef3232dc97b486af2d86e14042dbb65bbc535df562c3a858232488
>SHA256 emacs-28.2.tar.gz
>a6912b14ef4abb1edab7f88191bfd61c3edd7085e084de960a4f86485cb7cad8
>
>Emacs 28.2 is a bug-fix release, with no new features with 
>respect to
>Emacs 28.1.
>
>For the complete list of changes and the people who made them, 
>see the
>various ChangeLog files in the source distribution.  For a 
>summary of
>all the people who have contributed to Emacs, see the etc/AUTHORS 
>file.
>
>The online manuals and website will be updated shortly.
>
>Printed copies of the Emacs manual are available for purchase 
>from the
>Free Software Foundation's online store at:
>  https://shop.fsf.org/product/emacs-manual/
>
>For more information about Emacs, see:
>  https://www.gnu.org/software/emacs

Re: Emacs 28.2 released

[Stefan Kangas]

Karl Fogel <kfogel@red-bean.com> writes:

> Since these release announcement emails are widely shared (I saw
> this one appear on news.ycombinator.com, for example), it might be
> good to include a link to corresponding release notes.

Good idea.  Maybe we should start making an HTML export of the release
notes and publish it on the website?

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 12 Sep 2022 21:36:57 -0400
> Cc: emacs-devel@gnu.org
> 
> Karl Fogel <kfogel@red-bean.com> writes:
> 
> > Since these release announcement emails are widely shared (I saw
> > this one appear on news.ycombinator.com, for example), it might be
> > good to include a link to corresponding release notes.
> 
> Good idea.  Maybe we should start making an HTML export of the release
> notes and publish it on the website?

We already do that, see the web site.  It's just that the page was not
updated for this release yet.

Re: Emacs 28.2 released

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Maybe we should start making an HTML export of the release notes and
>> publish it on the website?
>
> We already do that, see the web site.

We just copy the plain text, right?

https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.28.2

> It's just that the page was not updated for this release yet.

It should be done now.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 13 Sep 2022 05:39:52 -0400
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Maybe we should start making an HTML export of the release notes and
> >> publish it on the website?
> >
> > We already do that, see the web site.
> 
> We just copy the plain text, right?

Yes.  That was one of Karl's proposals, right?

> https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.28.2

I think this is enough.  Reworking our humongous NEWS into HTML is too
much, and most people won't read that anyway.  This is why we have a
short list of the most important new features right there on the page.

> > It's just that the page was not updated for this release yet.
> 
> It should be done now.

Thanks!

Re: Emacs 28.2 released

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.28.2
>
> I think this is enough.  Reworking our humongous NEWS into HTML is too
> much, and most people won't read that anyway.

I was thinking of using something like org-mode to export it to HTML.
I don't think it would take much coding, really.

But I'm fine with leaving it alone, too.

Re: Emacs 28.2 released

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I was thinking of using something like org-mode to export it to HTML.
> I don't think it would take much coding, really.
>
> But I'm fine with leaving it alone, too.

I think that's a good idea -- our NEWS file uses a very regular syntax,
and writing a converter into Org format (and then exporting it to HTML)
doesn't sound like a major job.

Re: Emacs 28.2 released

[Robert Pluim]

>>>>> On Tue, 13 Sep 2022 15:03:24 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Stefan Kangas <stefankangas@gmail.com> writes:
    >> I was thinking of using something like org-mode to export it to HTML.
    >> I don't think it would take much coding, really.
    >> 
    >> But I'm fine with leaving it alone, too.

    Lars> I think that's a good idea -- our NEWS file uses a very regular syntax,
    Lars> and writing a converter into Org format (and then exporting it to HTML)
    Lars> doesn't sound like a major job.

Converter? You can just do

M-x org-mode RET
M-x org-export-dispatch h h

And it produces a nice html file. We might consider turning off the
table of contents, though.

Robert
-- 

Re: Emacs 28.2 released

[Lars Ingebrigtsen]

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

Robert Pluim <rpluim@gmail.com> writes:

> Converter? You can just do
>
> M-x org-mode RET
> M-x org-export-dispatch h h
>
> And it produces a nice html file.


[-- Attachment #2: Type: image/png, Size: 243006 bytes --]

Re: Emacs 28.2 released

[Karl Fogel]

On 13 Sep 2022, Eli Zaretskii wrote:
>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Tue, 13 Sep 2022 05:39:52 -0400
>> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Maybe we should start making an HTML export of the release 
>> >> notes and
>> >> publish it on the website?
>> >
>> > We already do that, see the web site.
>> 
>> We just copy the plain text, right?
>
>Yes.  That was one of Karl's proposals, right?

My proposal was that the email announcement should always contain 
a link to release notes, so that those who see the email can 
easily go straight to more details about what's in the new 
release.

Somehow, the followup discussion to my suggestion seems to have 
become about improving the format of the release notes themselves, 
or about offering various different formats / levels of detail of 
release notes.  Those might all be good ideas, but they're 
separate from what I was suggesting.

Best regards,
-Karl

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 13 Sep 2022 10:29:36 -0500
> 
> My proposal was that the email announcement should always contain 
> a link to release notes, so that those who see the email can 
> easily go straight to more details about what's in the new 
> release.

If so, I'm not sure I agree.  Other projects do that, or even post the
entire contents of NEWS as part of the announcement.  But our NEWS is
so large that posting it really makes no sense, and I won't expect
anyone to read the entire NEWS file, only search it for issues
relevant to him/her.

This is one case where doing what others do makes no sense.

Re: Emacs 28.2 released

[Eli Zaretskii]

> Date: Tue, 13 Sep 2022 18:49:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> 
> > From: Karl Fogel <kfogel@red-bean.com>
> > Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> > Date: Tue, 13 Sep 2022 10:29:36 -0500
> > 
> > My proposal was that the email announcement should always contain 
> > a link to release notes, so that those who see the email can 
> > easily go straight to more details about what's in the new 
> > release.
> 
> If so, I'm not sure I agree.  Other projects do that, or even post the
> entire contents of NEWS as part of the announcement.  But our NEWS is
> so large that posting it really makes no sense, and I won't expect
> anyone to read the entire NEWS file, only search it for issues
> relevant to him/her.
> 
> This is one case where doing what others do makes no sense.

And one more thing: announcements of major releases do include a short
list of main new features.  This is minor release, where the only
"new" things are bugfixes, so we don't include such a list in this
case.

Windows Binaries for Emacs 28.2 released

[Corwin Brust]

On Mon, Sep 12, 2022 at 5:13 AM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Version 28.2 of Emacs, the extensible text editor, should now
> be available from your nearest GNU mirror:

Binaries for Emacs 28.2 targeting Microsoft Windows are now available, as well.

Installer:
  https://ftp.gnu.org/gnu/emacs/windows/emacs-28/emacs-28.2-installer.exe
  https://ftp.gnu.org/gnu/emacs/windows/emacs-28/emacs-28.2-installer.exe.sig

Zip:
  https://ftp.gnu.org/gnu/emacs/windows/emacs-28/emacs-28.2.zip
  https://ftp.gnu.org/gnu/emacs/windows/emacs-28/emacs-28.2.zip

File List:
  https://ftp.gnu.org/gnu/emacs/windows/emacs-28/?C=M;O=D

Here are SHA265 sums for files uploaded today:
  1e8d037882e61d3fadf44f4e6153f538b131e6b7f475dc59eb20d85052a83b1e
*emacs-28.2-installer.exe
  ad224f869487535fe2b5a79783a85a8cb52c71438926367d4a1beaec9ca4de6a
*emacs-28.2-no-deps.zip
  7a63e762df0a3ce22d4af41c871009c05596576d335cd32a1819e2467ac7abcc
*emacs-28.2.zip

You can get my public key (among other ways), by visiting my profile
page on GNU Savann and clicking the "Download GPG Key" link:
  https://savannah.gnu.org/users/carlc

For more information on Emacs 28.2 (i.e., to read the full context of
the message partially quoted, above) see the original release
announcement, here:
  https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00730.html

Re: Windows Binaries for Emacs 28.2 released

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Tue, 13 Sep 2022 12:23:19 -0500
> 
> On Mon, Sep 12, 2022 at 5:13 AM Stefan Kangas <stefankangas@gmail.com> wrote:
> >
> > Version 28.2 of Emacs, the extensible text editor, should now
> > be available from your nearest GNU mirror:
> 
> Binaries for Emacs 28.2 targeting Microsoft Windows are now available, as well.

Thanks.  But did you see bug#56639?  It looks like there was some
problem with generating loaddefs, and the question that worries me is
whether the same could have happened for the 28.2 binaries.

Could you please take a look?

Re: Windows Binaries for Emacs 28.2 released

[Corwin Brust]

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

On Tue, Sep 13, 2022, 12:47 Eli Zaretskii <eliz@gnu.org> wrote:

> did you see bug#56639?


I did not.

  It looks like there was some
> problem with generating loaddefs, and the question that worries me is
> whether the same could have happened for the 28.2 binaries.
>
> Could you please take a look?
>

I will look after work; I'm afraid I out of time in my lunch period.

>

[-- Attachment #2: Type: text/html, Size: 1138 bytes --]

Re: Windows Binaries for Emacs 28.2 released

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Tue, 13 Sep 2022 13:01:48 -0500
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Tue, Sep 13, 2022, 12:47 Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  did you see bug#56639?
> 
> I did not.

That's strange, because we CC'ed you at this address...

Re: Windows Binaries for Emacs 28.2 released

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Version 28.2 of Emacs, the extensible text editor, should now
>> > be available from your nearest GNU mirror:
>> 
>> Binaries for Emacs 28.2 targeting Microsoft Windows are now available, as well.
>
> Thanks.  But did you see bug#56639?  It looks like there was some
> problem with generating loaddefs, and the question that worries me is
> whether the same could have happened for the 28.2 binaries.
>
> Could you please take a look?

FWIW, the MSYS2/Mingw64 package which is going to be published soon does
not show this problem.

Re: Windows Binaries for Emacs 28.2 released

[Corwin Brust]

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

On Tue, Sep 13, 2022 at 1:13 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Tue, 13 Sep 2022 13:01:48 -0500
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> > On Tue, Sep 13, 2022, 12:47 Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >  did you see bug#56639?
> >
> > I did not.
>
> That's strange, because we CC'ed you at this address...

I don't find it that strange - I'm thousands of Emails "behind" at
present.  I would welcome suggestions (other than "be caught up on
Email/filter your email better") that would help me more readily
notice (especially bugs) where my attention is wanted.

In any case, I cannot reproduce bug#56639 on my local using the
binaries uploaded today.

Later today I will confirm whether I can reproduce using test machines.

The bug in question relates to a snapshot of the "master" branch.  I
tend to expect the problem is specific to snapshot builds, which I
create from a local git checkout using Phil's script
(admin/nt/dist-build/build-zips.sh -s), modulo some local changes
represented by the attached patch.   Release binaries, on the other
hand, I create from the tar.xy published for the given version, using
a few "simple" shell commands.  Here is the central such command I
used to create the set uploaded today:

(./configure --with-modules --without-dbus --with-native-compilation
--without-compress-install CFLAGS=-O2 && make install -j 20
prefix=/d/emacs-build/install/emacs-28.2) | tee ../emacs-28.2.log

[-- Attachment #2: emacs-28-build.patch --]
[-- Type: application/octet-stream, Size: 3698 bytes --]

diff --git a/admin/nt/dist-build/build-dep-zips.py b/admin/nt/dist-build/build-dep-zips.py
index c27045a001..9b8492ff0e 100755
--- a/admin/nt/dist-build/build-dep-zips.py
+++ b/admin/nt/dist-build/build-dep-zips.py
@@ -37,6 +37,7 @@
 mingw-w64-x86_64-librsvg
 mingw-w64-x86_64-libtiff
 mingw-w64-x86_64-libxml2
+mingw-w64-x86_64-gmp
 mingw-w64-x86_64-xpm-nox'''.split()
 
 DLL_REQ='''libgif
@@ -49,7 +50,9 @@
 librsvg
 libtiff
 libxml
-libXpm'''.split()
+libgmp
+libXpm
+libXpm-noX4'''.split()
 
 
 ## Options
@@ -101,7 +104,7 @@ def ntldd_munge(out):
 
         ## if it's the former, we want it, if its the later we don't
         splt = dep.split()
-        if len(splt) > 2 and "msys64" in splt[2]:
+        if len(splt) > 2 and "mingw64" in splt[2]:
             print("Adding dep", splt[0])
             rtn.append(splt[0].split(".")[0])
 
@@ -121,7 +124,7 @@ def ntldd_munge(out):
 
 ## Currently no packages seem to require this!
 ARCH_PKGS=[]
-SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
+SRC_REPO="https://repo.msys2.org/mingw/sources"
 
 
 def immediate_deps(pkg):
@@ -167,7 +170,7 @@ def download_source(tarball):
     if not os.path.exists("../emacs-src-cache/{}".format(tarball)):
         print("Downloading {}...".format(tarball))
         check_output_maybe(
-            "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}/download"
+            "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}"
             .format(tarball, SRC_REPO, tarball),
             shell=True
         )
diff --git a/admin/nt/dist-build/build-zips.sh b/admin/nt/dist-build/build-zips.sh
index 77d20a5a7b..014a39917d 100755
--- a/admin/nt/dist-build/build-zips.sh
+++ b/admin/nt/dist-build/build-zips.sh
@@ -48,12 +48,13 @@
         echo [build] Configuring Emacs
         $REPO_DIR/$BRANCH/configure \
             --without-dbus \
+            --with-native-compilation \
             --without-compress-install \
             $CACHE \
-            CFLAGS="$CFLAGS"
+            CFLAGS="$CFLAGS" 
     fi
 
-    make -j 4 $INSTALL_TARGET \
+    make -j 20 $INSTALL_TARGET ${NATIVE_COMP_EXTRA_MAKE_FLAGS} \
          prefix=$HOME/emacs-build/install/emacs-$VERSION
     cd $HOME/emacs-build/install/emacs-$VERSION
     zip -r -9 emacs-$OF_VERSION-no-deps.zip *
@@ -96,14 +97,15 @@ BUILD=
 BUILD_64=1
 GIT_UP=0
 CONFIG=1
-CFLAGS="-O2 -static"
+CFLAGS="-O2"
+NATIVE_COMP_EXTRA_MAKE_FLAGS= # e.g. "NATIVE_FULL_AOT=1"
 INSTALL_TARGET="install-strip"
 
 ## The location of the git repo
 REPO_DIR=$HOME/emacs-build/git/
 
 
-while getopts "gb:hnsiV:" opt; do
+while getopts "gb:hnsiFV:" opt; do
   case $opt in
     g)
         BUILD_32=0
@@ -120,20 +122,25 @@ REPO_DIR=
         REQUIRED_BRANCH=$OPTARG
         echo "Setting Required branch $REQUIRED_BRANCH"
         ;;
+    F)
+	NATIVE_COMP_EXTRA_MAKE_FLAGS="NATIVE_FULL_AOT=1"
+	;;
     V)
         VERSION=$OPTARG
         ;;
     s)
         SNAPSHOT="-snapshot"
-        CFLAGS="-O2 -static -g3"
+        CFLAGS="-O2 -g3"
         INSTALL_TARGET="install"
         ;;
     h)
         echo "build-zips.sh"
-        echo "  -b args -- build args branch"
+        echo "  -b arg -- build <arg> branch"
+        echo "  -V arg -- build <arg> version"
         echo "  -g git update and worktree only"
         echo "  -i build installer only"
         echo "  -n do not configure"
+        echo "  -F supply NATIVE_FULL_AOT to make"
         echo "  -s snapshot build"
         exit 0
         ;;
@@ -191,7 +198,7 @@ OF_VERSION=
     OF_VERSION="$VERSION-`date +%Y-%m-%d`"
     ## Use snapshot dependencies
     SNAPSHOT=1
-    CFLAGS="-O2 -static -g3"
+    CFLAGS="-O2 -g3"
     INSTALL_TARGET="install"
 fi
 

Re: Windows Binaries for Emacs 28.2 released

[Corwin Brust]

On Tue, Sep 13, 2022 at 12:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Tue, 13 Sep 2022 12:23:19 -0500
> >
> > On Mon, Sep 12, 2022 at 5:13 AM Stefan Kangas <stefankangas@gmail.com> wrote:
> > >
> > > Version 28.2 of Emacs, the extensible text editor, should now
> > > be available from your nearest GNU mirror:
> >
> > Binaries for Emacs 28.2 targeting Microsoft Windows are now available, as well.
>
> Thanks.  But did you see bug#56639?  It looks like there was some
> problem with generating loaddefs, and the question that worries me is
> whether the same could have happened for the 28.2 binaries.

I can't reproduce bug#56639 starting from the installer for Emacs 28.2
published today.  I tested just now using a "test" machine without any
existing Emacs (or MSYS, etc) installations.

I'm fairly confident that bug will turn out to be something with the
way I had been making "snapshot" binaries from the main development
branch.  (I haven't made any snapshot builds recently.)

Re: Windows Binaries for Emacs 28.2 released

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Tue, 13 Sep 2022 18:11:34 -0500
> Cc: emacs-devel@gnu.org
> 
> On Tue, Sep 13, 2022 at 12:47 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Corwin Brust <corwin@bru.st>
> > > Date: Tue, 13 Sep 2022 12:23:19 -0500
> > >
> > > On Mon, Sep 12, 2022 at 5:13 AM Stefan Kangas <stefankangas@gmail.com> wrote:
> > > >
> > > > Version 28.2 of Emacs, the extensible text editor, should now
> > > > be available from your nearest GNU mirror:
> > >
> > > Binaries for Emacs 28.2 targeting Microsoft Windows are now available, as well.
> >
> > Thanks.  But did you see bug#56639?  It looks like there was some
> > problem with generating loaddefs, and the question that worries me is
> > whether the same could have happened for the 28.2 binaries.
> 
> I can't reproduce bug#56639 starting from the installer for Emacs 28.2
> published today.  I tested just now using a "test" machine without any
> existing Emacs (or MSYS, etc) installations.
> 
> I'm fairly confident that bug will turn out to be something with the
> way I had been making "snapshot" binaries from the main development
> branch.  (I haven't made any snapshot builds recently.)

Thanks, if that was a singular failure that won't come back, we are
good, and this bug can be closed.

Re: Windows Binaries for Emacs 28.2 released

[Corwin Brust]

On Tue, Sep 13, 2022 at 1:27 PM Óscar Fuentes <ofv@wanadoo.es> wrote:
>
> FWIW, the MSYS2/Mingw64 package which is going to be published soon does
> not show this problem.

It seems likely to have been an error on my part in creating the
particular snapshot release that the report relates to.  I haven't
been able to recreate the problem so far, nor reproduce it using any
of the release builds I've made recently.

Re: Emacs 28.2 released

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

> You can just do
>
> M-x org-mode RET
> M-x org-export-dispatch h h
>
> And it produces a nice html file. We might consider turning off the
> table of contents, though.

It was a bit more work than that, but I've now pushed a preliminary
version to emacs-28.

See here for the result:

    https://www.gnu.org/software/emacs/news/NEWS.28.2.html

If we like it, we could change the links to go to HTML versions instead.
And then we could export HTML versions for old versions, if we want to.

Re: Emacs 28.2 released

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> It was a bit more work than that, but I've now pushed a preliminary
> version to emacs-28.
>
> See here for the result:
>
>     https://www.gnu.org/software/emacs/news/NEWS.28.2.html

Great; that looks really good.

> If we like it, we could change the links to go to HTML versions instead.
> And then we could export HTML versions for old versions, if we want to.

Older NEWS files might not be as stringent wrt. format as they currently
are, so that might be more work?  But if it's straightforward, then I'd
be all for having the older versions as HTML, too.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 14 Sep 2022 09:43:34 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> > You can just do
> >
> > M-x org-mode RET
> > M-x org-export-dispatch h h
> >
> > And it produces a nice html file. We might consider turning off the
> > table of contents, though.
> 
> It was a bit more work than that, but I've now pushed a preliminary
> version to emacs-28.
> 
> See here for the result:
> 
>     https://www.gnu.org/software/emacs/news/NEWS.28.2.html

This is mostly Emacs 28.1 NEWS (as expected), which IMNSHO is
misleading.

Once again, I don't think we should publish NEWS for minor releases.
At the very least, remove everything that pertains to previous
releases of the same major version.

Re: Emacs 28.2 released

[Karl Fogel]

On 14 Sep 2022, Stefan Kangas wrote:
>Robert Pluim <rpluim@gmail.com> writes:
>
>> You can just do
>>
>> M-x org-mode RET
>> M-x org-export-dispatch h h
>>
>> And it produces a nice html file. We might consider turning off 
>> the
>> table of contents, though.
>
>It was a bit more work than that, but I've now pushed a 
>preliminary
>version to emacs-28.
>
>See here for the result:
>
>    https://www.gnu.org/software/emacs/news/NEWS.28.2.html
>
>If we like it, we could change the links to go to HTML versions 
>instead.
>And then we could export HTML versions for old versions, if we 
>want to.

Very nice.  In the first item (1.1), you can see some 
misformatting has happened.  (I don't see that problem in any 
other items, from a quick scan.)

Best regards,
-Karl

Re: Emacs 28.2 released

[Karl Fogel]

On 13 Sep 2022, Eli Zaretskii wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, 
>> emacs-devel@gnu.org
>> Date: Tue, 13 Sep 2022 10:29:36 -0500
>> 
>> My proposal was that the email announcement should always 
>> contain 
>> a link to release notes, so that those who see the email can 
>> easily go straight to more details about what's in the new 
>> release.
>
>If so, I'm not sure I agree.  Other projects do that, or even 
>post the
>entire contents of NEWS as part of the announcement.  But our 
>NEWS is
>so large that posting it really makes no sense, and I won't 
>expect
>anyone to read the entire NEWS file, only search it for issues
>relevant to him/her.
>
>This is one case where doing what others do makes no sense.

I was not suggesting including the contents of the NEWS file.  I 
was suggesting including a *link to* the NEWS file, so that those 
who are interested can follow the link.

That is what others do -- I can't think of another project that 
doesn't do this in their release announcement emails, in fact -- 
and I think we should do it too.

Best regards,
-Karl

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 11:59:35 -0500
> 
> >If so, I'm not sure I agree.  Other projects do that, or even 
> >post the
> >entire contents of NEWS as part of the announcement.  But our 
> >NEWS is
> >so large that posting it really makes no sense, and I won't 
> >expect
> >anyone to read the entire NEWS file, only search it for issues
> >relevant to him/her.
> >
> >This is one case where doing what others do makes no sense.
> 
> I was not suggesting including the contents of the NEWS file.  I 
> was suggesting including a *link to* the NEWS file, so that those 
> who are interested can follow the link.

I responded to both these alternatives.

> That is what others do -- I can't think of another project that 
> doesn't do this in their release announcement emails, in fact -- 
> and I think we should do it too.

I disagree, for the reasons I explained.  If you want to try changing
my mind, you will have to allude to those reasons, not just reiterate
what you already said before.

Re: Emacs 28.2 released

[Karl Fogel]

>I was not suggesting including the contents of the NEWS file.  I 
>was
>suggesting including a *link to* the NEWS file, so that those who 
>are
>interested can follow the link.

I should have said: "a link to the NEWS file or some other web 
page that describes the release".

The key point is for the announcement email to link to a more 
detailed description of what's new in the release.  Whether that 
description is the NEWS file or something else is a separate 
question -- whatever it is, it'll have more information about the 
release than the email announcement has.

Best regards,
-Karl

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 12:06:17 -0500
> 
> >I was not suggesting including the contents of the NEWS file.  I 
> >was
> >suggesting including a *link to* the NEWS file, so that those who 
> >are
> >interested can follow the link.
> 
> I should have said: "a link to the NEWS file or some other web 
> page that describes the release".

But we already do that!  For a major release, the Web page includes
its main new features, and the Web page mentions them for a month
since the release.  And the announcement tells how to read the NEWS
file.  What is missing?

> The key point is for the announcement email to link to a more 
> detailed description of what's new in the release.

More detailed than what?

> Whether that description is the NEWS file or something else is a
> separate question -- whatever it is, it'll have more information
> about the release than the email announcement has.

Here's the list of main new features in Emacs 28.1, copied from
https://www.gnu.org/software/emacs/

  Emacs 28.1
  Released Apr 4, 2022

  Emacs 28.1 has a wide variety of new features, including:

      Native compilation of Lisp files
      Text shaping with HarfBuzz and drawing with Cairo
      Support for loading Secure Computing filters
      Much improved display of Emoji and Emoji sequences
      New system for documenting groups of functions
      A minor mode for context menus
      Mode-specific commands
      Emacs shows matching parentheses by default
      Many improvements and extensions to project.el

There's a link to NEWS for people who want that.

What is the problem for the email announcement to have the same list
of main new features, and refer to NEWS, as we already do, for those
who really want that?

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 18:47:51 +0200
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > It was a bit more work than that, but I've now pushed a preliminary
> > version to emacs-28.
> >
> > See here for the result:
> >
> >     https://www.gnu.org/software/emacs/news/NEWS.28.2.html
> 
> Great; that looks really good.

I don't like the result at all, and like even less what is intended to
be its usage.  So please don't install that.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 12:06:17 -0500
> 
> The key point is for the announcement email to link to a more 
> detailed description of what's new in the release.

The email announcement is a plain-text message.  It lists the main new
features of a major release, and explains how to access NEWS for more.

Why is anything else needed?

Re: Emacs 28.2 released

[Bob Rogers]

   From: Karl Fogel <kfogel@red-bean.com>
   Date: Wed, 14 Sep 2022 11:57:21 -0500

   On 14 Sep 2022, Stefan Kangas wrote:
   >Robert Pluim <rpluim@gmail.com> writes:
   >
   > . . .
   >
   >It was a bit more work than that, but I've now pushed a 
   >preliminary version to emacs-28.
   >
   >See here for the result:
   >
   >    https://www.gnu.org/software/emacs/news/NEWS.28.2.html
   >
   >If we like it, we could change the links to go to HTML versions 
   >instead.
   >And then we could export HTML versions for old versions, if we 
   >want to.

   Very nice.  In the first item (1.1), you can see some 
   misformatting has happened.  (I don't see that problem in any 
   other items, from a quick scan.)

   Best regards,
   -Karl

Item 6.2 has the following code snippet:

	(set-fontset-font t 'emoji
			  ~("My New Emoji Font" . "iso10646-1") nil ~prepend)

Notice how the quotes have been changed to twiddles.  (I wondered what
new reader syntax had been invented for describing emoji fonts . . .)

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: Emacs 28.2 released

[Karl Fogel]

I think I see where the miscommunication is coming from here.  Let 
me explain my suggestion more clearly:

Stefan's announcement mail was for 28.2, and has this sentence:

"Emacs 28.2 is a bug-fix release, with no new features with 
respect to Emacs 28.1."

That's probably why his email didn't have any link out to a 
description of the release -- because 28.2 has no new features; 
it's just bugfixes.

(You can see his mail here, for reference: 
https://mail.gnu.org/archive/html/emacs-devel/2022-09/msg00730.html)

What I'm saying is that *every* release announcement email should 
have a clickable link to the release notes for that release, even 
when we're only making a bugfix release.

There are a couple of reasons for this, one direct and one more 
subtle:

The direct reason is:

Many readers will want to be able to click on a link to see what's 
in the release, because even if it's only bugfixes, they'll want 
to know what those fixes were.  They're making a decision about 
whether to upgrade, and typically that decision involves reading 
the release notes.  So if we just point to the release notes for 
*every* release, always, we'll help smooth their decision process.

The more subtle reason is:

Some people who (for whatever reason) didn't upgrade from >= 27.x 
when 28.1 came out may decide to do so when they see the 28.2 
announcement.  Online release notes are usually structured so that 
if one is reading the notes for X.Y, it's very easy to get from 
there to the notes for X.(Y-1) -- you just scroll farther down in 
the web page, or you edit the URL in some obvious way, or 
something like that.  Thus, people who saw Stefan's announcement 
would have the following assumption in the back of their minds: 
"If I can get to the release notes for 28.2, it'll be an equally 
easy hop from there to the release notes for 28.1".  Therefore, 
including a link to the 28.2 release notes in the 28.2 
announcement email would help those who are upgrading from >= 27.x 
too, as well as those upgrading from 28.1.

So my suggestion is that release announcement emails always 
include a direct link to the release notes for that release, for 
the reasons given above.  And specifically, that we stick to this 
policy even for minor or bugfix releases.

I hope this clarifies.

Best regards,
-Karl

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 13:49:58 -0500
> 
> What I'm saying is that *every* release announcement email should 
> have a clickable link to the release notes for that release, even 
> when we're only making a bugfix release.

But we don't have any release notes for bugfix releases.  We don't
track bugs that we fix in such releases, and don't record them
anywhere except in Git logs.  We certainly don't record them in NEWS,
which is why what Stefan did misses your point.

> So my suggestion is that release announcement emails always 
> include a direct link to the release notes for that release, for 
> the reasons given above.  And specifically, that we stick to this 
> policy even for minor or bugfix releases.

For that to be possible, we should first have some record of the bugs
we fixed explained in a language that would be understandable to users
(as opposed to Emacs developers).  Such a record will most probably
mention only some of the bugfixes, since many of them are minor and
others don't tell anything to users.  So let's first discuss whether
we want such a record, and if we do, how this could be possible in
practice.  Until we have such a record, talking about publishing it in
a release announcement is meaningless.

Re: Emacs 28.2 released

[Karl Fogel]

On 14 Sep 2022, Eli Zaretskii wrote:
>But we don't have any release notes for bugfix releases.  We 
>don't
>track bugs that we fix in such releases, and don't record them
>anywhere except in Git logs.  We certainly don't record them in 
>NEWS,
>which is why what Stefan did misses your point.

We have an entry in NEWS for 28.2.

That entry has a substantive item about an installation change. 
There are also a couple of items listed under "Changes in 
Specialized Modes and Packages in Emacs 28.2" (although one of 
them says that the change was actually released in 28.1 and that 
we just forgot to include it in the release notes then).

>> So my suggestion is that release announcement emails always 
>> include a direct link to the release notes for that release, 
>> for 
>> the reasons given above.  And specifically, that we stick to 
>> this 
>> policy even for minor or bugfix releases.
>
>For that to be possible, we should first have some record of the 
>bugs
>we fixed explained in a language that would be understandable to 
>users
>(as opposed to Emacs developers).  Such a record will most 
>probably
>mention only some of the bugfixes, since many of them are minor 
>and
>others don't tell anything to users.  So let's first discuss 
>whether
>we want such a record, and if we do, how this could be possible 
>in
>practice.  Until we have such a record, talking about publishing 
>it in
>a release announcement is meaningless.

While that would certainly make better release notes, I can't say 
whether it's worth the effort, and anyway it's not required here. 
Even without us keeping such a record, the so-called "more subtle" 
point in my previous message still holds:

People who land on the 28.2 notes can easily find their way from 
there to the previous notes, and so on.  Since we don't know the 
version of Emacs the reader might be contemplating upgrading from, 
by linking from the announcement email to the corresponding recent 
release notes, we put the reader at a starting point from which 
they can easily trace back as far as they need to go to make their 
decision.

In other words, *even* if all we do for a minor release is put an 
entry into NEWS that says...

> * Changes in Emacs X.Y
> 
> This is a bug-fix release with no new features.

...and then we point to that (in whatever form it lives on the 
web), we are still helping the reader start their informational 
journey.

This also simplifies the release process a tiny bit, because it's 
an unconditional policy.  The email template would always have a 
slot for that link, and that link would always has a place to 
point to.

Best regards,
-Karl

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 14:15:26 -0500
> 
> On 14 Sep 2022, Eli Zaretskii wrote:
> >But we don't have any release notes for bugfix releases.  We 
> >don't
> >track bugs that we fix in such releases, and don't record them
> >anywhere except in Git logs.  We certainly don't record them in 
> >NEWS,
> >which is why what Stefan did misses your point.
> 
> We have an entry in NEWS for 28.2.
> 
> That entry has a substantive item about an installation change. 
> There are also a couple of items listed under "Changes in 
> Specialized Modes and Packages in Emacs 28.2" (although one of 
> them says that the change was actually released in 28.1 and that 
> we just forgot to include it in the release notes then).

These are not the bugfixes whose list you wanted to see.

> People who land on the 28.2 notes can easily find their way from 
> there to the previous notes, and so on.  Since we don't know the 
> version of Emacs the reader might be contemplating upgrading from, 
> by linking from the announcement email to the corresponding recent 
> release notes, we put the reader at a starting point from which 
> they can easily trace back as far as they need to go to make their 
> decision.
> 
> In other words, *even* if all we do for a minor release is put an 
> entry into NEWS that says...
> 
> > * Changes in Emacs X.Y
> > 
> > This is a bug-fix release with no new features.
> 
> ...and then we point to that (in whatever form it lives on the 
> web), we are still helping the reader start their informational 
> journey.

You keep changing the request on every step.  It is very hard to have
a useful discussion this way.

So now I understand that you suggest having something like this:

  . a link to NEWS of the current release (for minor releases, this
    NEWS could be empty or almost empty, and we don't have a way to
    describe the bugs we fixed there, but you now say this is not
    important?)
  . a link to the announcement of previous release, where there will
    be a link to NEWS of that release
  . and so on, all the way to some old enough release beyond which no
    one will bother

Is that correct?  Or do we have a misunderstanding again?

Re: Emacs 28.2 released

[Karl Fogel]

On 14 Sep 2022, Eli Zaretskii wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
>> Date: Wed, 14 Sep 2022 14:15:26 -0500
>> 
>> On 14 Sep 2022, Eli Zaretskii wrote:
>> >But we don't have any release notes for bugfix releases.  We 
>> >don't
>> >track bugs that we fix in such releases, and don't record them
>> >anywhere except in Git logs.  We certainly don't record them 
>> >in 
>> >NEWS,
>> >which is why what Stefan did misses your point.
>> 
>> We have an entry in NEWS for 28.2.
>> 
>> That entry has a substantive item about an installation change. 
>> There are also a couple of items listed under "Changes in 
>> Specialized Modes and Packages in Emacs 28.2" (although one of 
>> them says that the change was actually released in 28.1 and 
>> that 
>> we just forgot to include it in the release notes then).
>
>These are not the bugfixes whose list you wanted to see.

Sure it is.  It's good enough -- and presumably that's why we link 
to it from the 28.2 section on 
https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases 
.

All I'm saying is that the announcement email should contain the 
*same link* that the above page contains.

If we want to make further improvements to release notes, we can. 
I'm not against that.  But my core suggestion has always been to 
just link to the thing *that we already have*.  We don't need to 
do more work to make a better thing.  Let's just point to the 
thing we have -- that would already be an improvement on the 
status quo, and a very easy improvement to implement.

While the blurb for 28.2 may not be a complete list of bugfixes, 
it is still useful, both in what it contains and in its position 
at the end of an easily-navigable long line of past release notes.

>You keep changing the request on every step.  It is very hard to 
>have
>a useful discussion this way.

I have been making the same request in every single email.  My 
original email contains the same proposal I am making above:

https://mail.gnu.org/archive/html/emacs-devel/2022-09/msg00757.html

(Later I introduced the observation that readers of announcement 
emails will also use the *already existing* ability to easily get 
from the current release notes to past release notes.  That merely 
supplements the argument I've always been making -- it is an 
additional feature, but it doesn't require any extra work on our 
part: we already have it.)

>So now I understand that you suggest having something like this:
>
>  . a link to NEWS of the current release (for minor releases, 
>  this
>    NEWS could be empty or almost empty, and we don't have a way 
>    to
>    describe the bugs we fixed there, but you now say this is not
>    important?)
>  . a link to the announcement of previous release, where there 
>  will
>    be a link to NEWS of that release
>  . and so on, all the way to some old enough release beyond 
>  which no
>    one will bother
>
>Is that correct?  Or do we have a misunderstanding again?

I don't understand how you got that from what I wrote, but it is 
not what I said.

My suggestion is simply this:

Every release announcement email -- major or minor -- should have 
a link to the corresponding online release notes.

That single link is enough to satisfy readers who want to go 
looking for more detail.  Sure, we could improve our release notes 
for minor releases, if we decide it's worth the effort, but just 
dependably having the link at all would still be an improvement 
over the status quo.

In practice, some readers will use that to jump to information 
about older releases, since not everyone upgrades with every 
release.  Our online release notes are already presented in a way 
that makes such jumping convenient, so we don't need to do any 
more work to get that benefit.

Best regards,
-Karl

Re: Emacs 28.2 released

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > See here for the result:
>> >
>> >     https://www.gnu.org/software/emacs/news/NEWS.28.2.html
>>
>> Great; that looks really good.
>
> I don't like the result at all, and like even less what is intended to
> be its usage.

To clarify, the intention is to replace the link on

    https://www.gnu.org/software/emacs/#Releases

which currently points to

    https://www.gnu.org/software/emacs/news/NEWS.28.2

with

    https://www.gnu.org/software/emacs/news/NEWS.28.2.html

.

Re: Emacs 28.2 released

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Once again, I don't think we should publish NEWS for minor releases.
> At the very least, remove everything that pertains to previous
> releases of the same major version.

Do you suggest deleting and/or trimming this file too

    https://www.gnu.org/software/emacs/news/NEWS.28.2

?

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 14 Sep 2022 15:50:48 -0700
> Cc: rpluim@gmail.com, kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > See here for the result:
> >> >
> >> >     https://www.gnu.org/software/emacs/news/NEWS.28.2.html
> >>
> >> Great; that looks really good.
> >
> > I don't like the result at all, and like even less what is intended to
> > be its usage.
> 
> To clarify, the intention is to replace the link on
> 
>     https://www.gnu.org/software/emacs/#Releases
> 
> which currently points to
> 
>     https://www.gnu.org/software/emacs/news/NEWS.28.2
> 
> with
> 
>     https://www.gnu.org/software/emacs/news/NEWS.28.2.html

First, this was not what Karl was talking about (AFAIU, and it sounds
like I might be misunderstanding -- again).  He asked to include a
link in the email announcement we post to various GNU mailing lists,
whereas the above replaces the link on the Emacs Web site, which is a
different place.  I was talking about what I perceived was Karl's
request.

Second, to evaluate your proposal, please describe what is needed
(which commands and packages, and how to use them) to produce this
HTML version.  Also, how will this HTML version be maintained, after
it is produced.  I don't think you described all that in detail;
apologies if I missed something.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 14 Sep 2022 15:50:56 -0700
> Cc: rpluim@gmail.com, larsi@gnus.org, kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Once again, I don't think we should publish NEWS for minor releases.
> > At the very least, remove everything that pertains to previous
> > releases of the same major version.
> 
> Do you suggest deleting and/or trimming this file too
> 
>     https://www.gnu.org/software/emacs/news/NEWS.28.2
> 
> ?

No.

Re: Emacs 28.2 released

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 14:53:43 -0500
> 
> >> We have an entry in NEWS for 28.2.
> >> 
> >> That entry has a substantive item about an installation change. 
> >> There are also a couple of items listed under "Changes in 
> >> Specialized Modes and Packages in Emacs 28.2" (although one of 
> >> them says that the change was actually released in 28.1 and 
> >> that 
> >> we just forgot to include it in the release notes then).
> >
> >These are not the bugfixes whose list you wanted to see.
> 
> Sure it is.  It's good enough -- and presumably that's why we link 
> to it from the 28.2 section on 
> https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases 
> .

Are we talking about the email announcements or are we talking about
the Emacs Web page?  They are two different media, and I thought you
were talking about the former.

The email announcement of a major release (in this case, Emacs 28.1)
has this text:

  For a summary of changes in Emacs 28.1, see the etc/NEWS file in the
  tarball; you can view it from Emacs by typing 'C-h n', or by clicking
  Help->Emacs News from the menu bar.

  For the complete list of changes and the people who made them, see the
  various ChangeLog files in the source distribution.  For a summary of
  all the people who have contributed to Emacs, see the etc/AUTHORS
  file.

AFAIU, you wanted to have there an HTML link to the NEWS file, is that
correct?  If so, I can suggest adding to the above text the link to

  https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-28

Would that be okay?

One subtle issue here is that when we post the email announcement
about a new release, the on-line manuals and the Emacs Web page are
not yet up-to-date, so either a link to anything inside the Web pages
will be outdated, or we will need to delay the announcement until the
Web pages are updated, both of which are undesirable.  A link to Git
above is thus a compromise that doesn't have these disadvantages.

> All I'm saying is that the announcement email should contain the 
> *same link* that the above page contains.

See above: that'd delay the release announcement, sometimes by days,
depending on the free time of the people who do these updating jobs.

> While the blurb for 28.2 may not be a complete list of bugfixes, 
> it is still useful, both in what it contains and in its position 
> at the end of an easily-navigable long line of past release notes.

As explained already, that blurb is not a list of bugfixes at all.  It
is a list of noteworthy changes in the release, and in minor releases
it is usually very short, sometimes includes "old news" from the
previous releases that we just forgot to mention, and could even be
empty.  I don't especially mind having that referenced in the email
announcements, but if that satisfies your request, I really wonder
what was all the fuss about.

> >You keep changing the request on every step.  It is very hard to 
> >have
> >a useful discussion this way.
> 
> I have been making the same request in every single email.  My 
> original email contains the same proposal I am making above:

No, it didn't, not in this detail and accuracy.

> >Is that correct?  Or do we have a misunderstanding again?
> 
> I don't understand how you got that from what I wrote, but it is 
> not what I said.

As already mentioned, it is hard to understand what exactly are you
saying.  Apologies for not being better at that.

> My suggestion is simply this:
> 
> Every release announcement email -- major or minor -- should have 
> a link to the corresponding online release notes.

If by "release notes" you mean the NEWS file, this can be done,
although I question the usefulness.  If you mean something else, then
we don't have any "release notes" in Emacs; however the Emacs Web page
does show a list of the more important new features in each major
release.

> That single link is enough to satisfy readers who want to go 
> looking for more detail.

What is this assertion based on?  I understand that doing so will
satisfy you, but how do you know it will satisfy others?

Re: Emacs 28.2 released

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I was talking about what I perceived was Karl's request.

Sorry, it's my bad for getting an idea in the middle of a discussion and
then not explaining it clearly.  As my idea is orthogonal to Karl's, I
will make a separate email where I will describe my proposal in more
detail.

Re: Emacs 28.2 released

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, you wanted to have there an HTML link to the NEWS file, is that
> correct?  If so, I can suggest adding to the above text the link to
>
>   https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-28
>
> Would that be okay?

That proposal sounds okay to me, FWIW.

> One subtle issue here is that when we post the email announcement
> about a new release, the on-line manuals and the Emacs Web page are
> not yet up-to-date, so either a link to anything inside the Web pages
> will be outdated, or we will need to delay the announcement until the
> Web pages are updated, both of which are undesirable.  A link to Git
> above is thus a compromise that doesn't have these disadvantages.

That's exactly right.  While I do happen to think there is room for more
automation here, the link to git is a good compromise for now.

Re: Emacs 28.2 released

[Karl Fogel]

On 15 Sep 2022, Eli Zaretskii wrote:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
>> Date: Wed, 14 Sep 2022 14:53:43 -0500
>> 
>> >> We have an entry in NEWS for 28.2.
>> >> 
>> >> That entry has a substantive item about an installation 
>> >> change. 
>> >> There are also a couple of items listed under "Changes in 
>> >> Specialized Modes and Packages in Emacs 28.2" (although one 
>> >> of 
>> >> them says that the change was actually released in 28.1 and 
>> >> that 
>> >> we just forgot to include it in the release notes then).
>> >
>> >These are not the bugfixes whose list you wanted to see.
>> 
>> Sure it is.  It's good enough -- and presumably that's why we 
>> link 
>> to it from the 28.2 section on 
>> https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases 
>> .
>
>Are we talking about the email announcements or are we talking 
>about
>the Emacs Web page?  They are two different media, and I thought 
>you
>were talking about the former.

We're talking about making a change to email announcements.

The fact that we already link to the minor release's NEWS file 
from the "#Releases" section of the web site indicates that we 
think the contents of those NEWS files to be noteworthy for the 
release.  We're already using them, effectively, as release notes 
-- they are, after all, notes about the release, that we link to 
from our web page about releases.  (I could have been clearer 
about the fact that I was using "release notes" as a shorthand 
phrase to refer this information that we already post to the web 
to accompany a release.)

>The email announcement of a major release (in this case, Emacs 
>28.1)
>has this text:
>
>  For a summary of changes in Emacs 28.1, see the etc/NEWS file 
>  in the
>  tarball; you can view it from Emacs by typing 'C-h n', or by 
>  clicking
>  Help->Emacs News from the menu bar.
>
>  For the complete list of changes and the people who made them, 
>  see the
>  various ChangeLog files in the source distribution.  For a 
>  summary of
>  all the people who have contributed to Emacs, see the 
>  etc/AUTHORS
>  file.
>
>AFAIU, you wanted to have there an HTML link to the NEWS file, is 
>that
>correct?  If so, I can suggest adding to the above text the link 
>to
>
>  https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-28
>
>Would that be okay?

Yes.

There have been separate followup discussions here of improving 
the in-browser presentation of that information, and/or making the 
URL something a little more familiar, and those would be welcome 
improvements, but just doing the above would solve the problem -- 
we would now have a clickable link.

>One subtle issue here is that when we post the email announcement
>about a new release, the on-line manuals and the Emacs Web page 
>are
>not yet up-to-date, so either a link to anything inside the Web 
>pages
>will be outdated, or we will need to delay the announcement until 
>the
>Web pages are updated, both of which are undesirable.  A link to 
>Git
>above is thus a compromise that doesn't have these disadvantages.

I didn't know about that process ordering issue.  In that case, a 
simple solution is just a link to Git, as you suggest.

>> All I'm saying is that the announcement email should contain 
>> the 
>> *same link* that the above page contains.
>
>See above: that'd delay the release announcement, sometimes by 
>days,
>depending on the free time of the people who do these updating 
>jobs.

Yup; I didn't know about that ordering issue.  But a link to the 
exact same information (at this different, Git-based URL) is fine.

>> While the blurb for 28.2 may not be a complete list of 
>> bugfixes, 
>> it is still useful, both in what it contains and in its 
>> position 
>> at the end of an easily-navigable long line of past release 
>> notes.
>
>As explained already, that blurb is not a list of bugfixes at 
>all.  It
>is a list of noteworthy changes in the release, and in minor 
>releases
>it is usually very short, sometimes includes "old news" from the
>previous releases that we just forgot to mention, and could even 
>be
>empty.  I don't especially mind having that referenced in the 
>email
>announcements, but if that satisfies your request, I really 
>wonder
>what was all the fuss about.

"A list of noteworthy changes in the release" sounds like a 
description of release notes, and is good enough.  If some day we 
have a chance to make even more information easily available, 
that's even better, but no need to wait for that.

>If by "release notes" you mean the NEWS file, this can be done,
>although I question the usefulness.

I assumed that if we are maintaining the NEWS file entries, we 
must think they are useful news.  Otherwise, why are we writing 
them?

>If you mean something else, then
>we don't have any "release notes" in Emacs; however the Emacs Web 
>page
>does show a list of the more important new features in each major
>release.
>
>> That single link is enough to satisfy readers who want to go 
>> looking for more detail.
>
>What is this assertion based on?  I understand that doing so will
>satisfy you, but how do you know it will satisfy others?

I tried to explain this in an earlier post, where I wrote:

> Online release notes are usually structured so that 
> if one is reading the notes for X.Y, it's very easy to get from 
> there to the notes for X.(Y-1) -- you just scroll farther down 
> in 
> the web page, or you edit the URL in some obvious way, or 
> something like that.  Thus, people who saw Stefan's announcement 
> would have the following assumption in the back of their minds: 
> "If I can get to the release notes for 28.2, it'll be an equally 
> easy hop from there to the release notes for 28.1".  Therefore, 
> including a link to the 28.2 release notes in the 28.2 
> announcement email would help those who are upgrading from >= 
> 27.x 
> too, as well as those upgrading from 28.1.

What I said there applies (for example) to the NEWS file link you 
give above.

Once someone has landed on the Git-served NEWS web page, they can 
easily find their way to earlier release notes if the wish to.  In 
this case they would do it by searching farther down in the same 
page.  In other cases, such as if they had landed on 
https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.28, they 
might might do it via trivial URL editing.

These are common strategies that people who install software like 
Emacs generally know how to use.  I would expect that you yourself 
have used such strategies before, though I don't know for sure.

Best regards,
-Karl

Re: Emacs 28.2 released

[Stefan Kangas]

Karl Fogel <kfogel@red-bean.com> writes:

> Very nice.  In the first item (1.1), you can see some
> misformatting has happened.  (I don't see that problem in any
> other items, from a quick scan.)

Bob Rogers <rogers@rgrjr.com> writes:

> Item 6.2 has the following code snippet:
>
> 	(set-fontset-font t 'emoji
> 			  ~("My New Emoji Font" . "iso10646-1") nil ~prepend)
>
> Notice how the quotes have been changed to twiddles.  (I wondered what
> new reader syntax had been invented for describing emoji fonts . . .)

Both of the above errors should now be fixed, see:

    https://www.gnu.org/software/emacs/news/NEWS.28.html

(Note that the old file NEWS.28.2.html has been deleted.)