Re: Emacs 28.2 released

[Karl Fogel <kfogel@red-bean.com>]

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