Re: master e714b31 3/6: Merge from origin/emacs-28

Re: master e714b31 3/6: Merge from origin/emacs-28

[Robert Pluim]

>>>>> On Sat,  6 Nov 2021 05:24:32 -0400 (EDT), eliz@gnu.org (Eli Zaretskii) said:

    Eli> branch: master
    Eli> commit e714b314037feeb5ce7294231d0d2ce9ca09b847
    Eli> Merge: 3517b32 4cc22f8
    Eli> Author: Eli Zaretskii <eliz@gnu.org>
    Eli> Commit: Eli Zaretskii <eliz@gnu.org>

    Eli>  +++
    Eli> -*** 'slot-value' can now be used to read slots of 'cl-defstruct' objects

This line was a merge error, which Iʼve fixed. There may be more
lurking.

I vote +1 on the suggestion to just start using etc/NEWS.29

Robert
-- 

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Monnier]

> I vote +1 on the suggestion to just start using etc/NEWS.29

You got my vote as well,


        Stefan

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 10 Nov 2021 16:55:40 +0100
> 
>     Eli>  +++
>     Eli> -*** 'slot-value' can now be used to read slots of 'cl-defstruct' objects
> 
> This line was a merge error, which Iʼve fixed. There may be more
> lurking.

Sorry about that.

> I vote +1 on the suggestion to just start using etc/NEWS.29

I think I found the reason why merging NEWS didn't work for me, so it
won't happen again.  There was sufficient resistance to using a
versioned name, so we should stick to what we have as long as it works
well enough.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Robert Pluim]

>>>>> On Wed, 10 Nov 2021 19:12:20 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>
    >> Date: Wed, 10 Nov 2021 16:55:40 +0100
    >> 
    Eli> +++
    Eli> -*** 'slot-value' can now be used to read slots of 'cl-defstruct' objects
    >> 
    >> This line was a merge error, which Iʼve fixed. There may be more
    >> lurking.

    Eli> Sorry about that.

Merging NEWS is easy to get wrong, especially with the '+++' '---'
markers (I got it wrong when fixing the merge, and was about to blame
Stefan for not documenting his changes 😼).

    >> I vote +1 on the suggestion to just start using etc/NEWS.29

    Eli> I think I found the reason why merging NEWS didn't work for me, so it
    Eli> won't happen again.  There was sufficient resistance to using a
    Eli> versioned name, so we should stick to what we have as long as it works
    Eli> well enough.

OK.

Robert
-- 

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> There was sufficient resistance to using a versioned name,

What resistance?  I see only overwhelming support based on this thread
and e.g. these:

https://lists.gnu.org/r/emacs-devel/2017-12/msg00340.html
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29366

> so we should stick to what we have as long as it works well enough.

I think we have proof that it doesn't.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Juri Linkov]

>     >> I vote +1 on the suggestion to just start using etc/NEWS.29
>
>     Eli> I think I found the reason why merging NEWS didn't work for me, so it
>     Eli> won't happen again.  There was sufficient resistance to using a
>     Eli> versioned name, so we should stick to what we have as long as it works
>     Eli> well enough.
>
> OK.

Unfortunately, this is not quite OK.  I had to scrape the remains of NEWS.28
out of the NEWS in master.  Thanks for the reference to the commit e714b31,
this helped a lot.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Juri Linkov]

>>     >> I vote +1 on the suggestion to just start using etc/NEWS.29
>>
>>     Eli> I think I found the reason why merging NEWS didn't work for me, so it
>>     Eli> won't happen again.  There was sufficient resistance to using a
>>     Eli> versioned name, so we should stick to what we have as long as it works
>>     Eli> well enough.
>>
>> OK.
>
> Unfortunately, this is not quite OK.  I had to scrape the remains of NEWS.28
> out of the NEWS in master.  Thanks for the reference to the commit e714b31,
> this helped a lot.

Actually, this is not the full story.  I had also to re-add changes
omitted in the merge from NEWS in emacs-28 to NEWS-28.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 10 Nov 2021 18:18:14 +0100
> 
> Merging NEWS is easy to get wrong, especially with the '+++' '---'
> markers (I got it wrong when fixing the merge, and was about to blame
> Stefan for not documenting his changes 😼).

We don't actually merge NEWS, see gitmerge.el.  the way we do it,
there can be no problems, ever.

The problem in my case was that the code there relied on some feature
of Patch that my version here doesn't have, so it failed.  And, as
many things in gitmerge, this failure was more or less silent, so as
someone who did this for the first time, it was hard for me to
understand that I was looking at a bug and not at something the code
was intended to do.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 10 Nov 2021 09:49:42 -0800
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There was sufficient resistance to using a versioned name,
> 
> What resistance?  I see only overwhelming support based on this thread
> and e.g. these:
> 
> https://lists.gnu.org/r/emacs-devel/2017-12/msg00340.html
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29366

I guess we read different discussions, then.

> > so we should stick to what we have as long as it works well enough.
> 
> I think we have proof that it doesn't.

How can a simple bug in gitmerge be a proof of anything (except that
bugs happen)?

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 10 Nov 2021 20:37:09 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> >>     >> I vote +1 on the suggestion to just start using etc/NEWS.29
> >>
> >>     Eli> I think I found the reason why merging NEWS didn't work for me, so it
> >>     Eli> won't happen again.  There was sufficient resistance to using a
> >>     Eli> versioned name, so we should stick to what we have as long as it works
> >>     Eli> well enough.
> >>
> >> OK.
> >
> > Unfortunately, this is not quite OK.  I had to scrape the remains of NEWS.28
> > out of the NEWS in master.  Thanks for the reference to the commit e714b31,
> > this helped a lot.
> 
> Actually, this is not the full story.  I had also to re-add changes
> omitted in the merge from NEWS in emacs-28 to NEWS-28.

I'm sorry for the trouble, but we all sometimes need to clean up after
someone else in the repository.  I do that almost every day.  So I
hope I can be forgiven for this single incident, just this once.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Juri Linkov]

>> >>     >> I vote +1 on the suggestion to just start using etc/NEWS.29
>> >>
>> >>     Eli> I think I found the reason why merging NEWS didn't work for me, so it
>> >>     Eli> won't happen again.  There was sufficient resistance to using a
>> >>     Eli> versioned name, so we should stick to what we have as long as it works
>> >>     Eli> well enough.
>> >>
>> >> OK.
>> >
>> > Unfortunately, this is not quite OK.  I had to scrape the remains of NEWS.28
>> > out of the NEWS in master.  Thanks for the reference to the commit e714b31,
>> > this helped a lot.
>>
>> Actually, this is not the full story.  I had also to re-add changes
>> omitted in the merge from NEWS in emacs-28 to NEWS-28.
>
> I'm sorry for the trouble, but we all sometimes need to clean up after
> someone else in the repository.  I do that almost every day.  So I
> hope I can be forgiven for this single incident, just this once.

No problem for me.  But such incidents show why this complicated merging
looks scary, so I still hesitate to merge from emacs-28 myself :-)

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 10 Nov 2021 21:06:20 +0200
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> >> Actually, this is not the full story.  I had also to re-add changes
> >> omitted in the merge from NEWS in emacs-28 to NEWS-28.
> >
> > I'm sorry for the trouble, but we all sometimes need to clean up after
> > someone else in the repository.  I do that almost every day.  So I
> > hope I can be forgiven for this single incident, just this once.
> 
> No problem for me.  But such incidents show why this complicated merging
> looks scary, so I still hesitate to merge from emacs-28 myself :-)

That's okay.  You don't have to feel bad, there's more than enough
people who merge regularly.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> https://lists.gnu.org/r/emacs-devel/2017-12/msg00340.html
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29366
>
> I guess we read different discussions, then.

I read the above.  Which discussions are you reading?

Let's count heads: Robert Pluim, Michael Albinus, Stefan Monnier, Stefan
Kangas, Glenn Morris, Juri Linkov have AFAICT all come out in support of
this change.  Some more forcefully than others.

I don't see anyone against the change.

> How can a simple bug in gitmerge be a proof of anything (except that
> bugs happen)?

The existence of the special code for this in gitmerge is already proof
that this is suboptimal.  If it is buggy, that makes it worse of course.

But even if there are no bugs in gitmerge.el, today or in the future, we
still lose the ability to use "git blame" in etc/NEWS.NN for the
previous release on master.

And what's the upside?  None, AFAICT.

Instead of working against fundamental limitations in git, it is easy or
even trivial to completely side-step the issue.  AFAICT, the attached
patch fixes this on GNU/Linux, but I think you would need to do more on
operating systems without symlink support.  (There is obviously also
more stuff to do in gitmerge.el and the install step.  I didn't bother
for this quick proof-of-concept though.)

[-- Attachment #2: 0001-Move-etc-NEWS-to-etc-NEWS.NN.patch --]
[-- Type: text/x-diff, Size: 2185 bytes --]

From 64f7877d803d8ab7870469437bd6809e68142f42 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 10 Nov 2021 18:11:36 +0100
Subject: [PATCH] Move etc/NEWS to etc/NEWS.NN

* etc/NEWS: Move from here...
* etc/NEWS.29: ...to here.
* .gitignore: Ignore NEWS.
* autogen.sh: Symlink etc/NEWS to etc/NEWS.NN.
* src/callproc.c (init_callproc): Search for the etc/ directory based
on the "TODO" file instead of "NEWS".
---
 .gitignore            | 1 +
 autogen.sh            | 5 +++++
 etc/{NEWS => NEWS.29} | 0
 src/callproc.c        | 4 ++--
 4 files changed, 8 insertions(+), 2 deletions(-)
 rename etc/{NEWS => NEWS.29} (100%)

diff --git a/.gitignore b/.gitignore
index ea1662c9b8..c212340da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -264,6 +264,7 @@ doc/misc/cc-mode.ss
 doc/misc/modus-themes.texi
 doc/misc/org.texi
 etc/DOC
+etc/NEWS
 etc/refcards/emacsver.tex
 gnustmp*
 /info/
diff --git a/autogen.sh b/autogen.sh
index 531e5775f9..1112fadd63 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -140,6 +140,11 @@ do_git=
     test -r .git && do_git=true;;
 esac
 
+# Symlink NEWS
+if [ ! -e etc/NEWS ]; then
+    ln -s "$(ls -1 etc/NEWS.* | tail -1)" etc/NEWS
+fi
+
 # Generate Autoconf-related files, if requested.
 
 if $do_autoconf; then
diff --git a/etc/NEWS b/etc/NEWS.29
similarity index 100%
rename from etc/NEWS
rename to etc/NEWS.29
diff --git a/src/callproc.c b/src/callproc.c
index fa43f97384..f0354320f7 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1733,13 +1733,13 @@ init_callproc (void)
 
       srcdir = Fexpand_file_name (build_string ("../src/"), lispdir);
 
-      tem = Fexpand_file_name (build_string ("NEWS"), Vdata_directory);
+      tem = Fexpand_file_name (build_string ("TODO"), Vdata_directory);
       if (!NILP (Fequal (srcdir, Vinvocation_directory))
 	  || NILP (Ffile_exists_p (tem)) || !NILP (Vinstallation_directory))
 	{
 	  Lisp_Object newdir;
 	  newdir = Fexpand_file_name (build_string ("../etc/"), lispdir);
-	  tem = Fexpand_file_name (build_string ("NEWS"), newdir);
+	  tem = Fexpand_file_name (build_string ("TODO"), newdir);
 	  if (!NILP (Ffile_exists_p (tem)))
 	    Vdata_directory = newdir;
 	}
-- 
2.30.2

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 10 Nov 2021 11:19:51 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> >> https://lists.gnu.org/r/emacs-devel/2017-12/msg00340.html
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29366
> >
> > I guess we read different discussions, then.
> 
> I read the above.  Which discussions are you reading?
> 
> Let's count heads: Robert Pluim, Michael Albinus, Stefan Monnier, Stefan
> Kangas, Glenn Morris, Juri Linkov have AFAICT all come out in support of
> this change.  Some more forcefully than others.
> 
> I don't see anyone against the change.

Look closer, please.

> > How can a simple bug in gitmerge be a proof of anything (except that
> > bugs happen)?
> 
> The existence of the special code for this in gitmerge is already proof
> that this is suboptimal.  If it is buggy, that makes it worse of course.

Nonsense.  It just means we haven't yet got the full solution for
that.  Any code has bugs, and they tend to pop up when people other
than the person who wrote it start using it more intensively.  This
always happens in development, and is not proof of anything.

> But even if there are no bugs in gitmerge.el, today or in the future, we
> still lose the ability to use "git blame" in etc/NEWS.NN for the
> previous release on master.

"git annotate" on NEWS is pretty meaningless anyway.  Stuff gets moved
there too much for that to be useful.

> And what's the upside?  None, AFAICT.

You are biased, so you only see the side that suits you.  The upside
is that we are using this for a long time, and any problems we see now
are minor.  You propose a revolution where a simple bugfix should be
enough.

> Instead of working against fundamental limitations in git, it is easy or
> even trivial to completely side-step the issue.  AFAICT, the attached
> patch fixes this on GNU/Linux, but I think you would need to do more on
> operating systems without symlink support.  (There is obviously also
> more stuff to do in gitmerge.el and the install step.  I didn't bother
> for this quick proof-of-concept though.)

Thanks, but I'm not interested in doing this.  Let's move on to more
important stuff.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> https://lists.gnu.org/r/emacs-devel/2017-12/msg00340.html
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29366
>
> I guess we read different discussions, then.

I read the above.  Which discussions are you reading?

Let's count heads: Robert Pluim, Michael Albinus, Stefan Monnier, Stefan
Kangas, Glenn Morris, Juri Linkov have AFAICT all come out in support of
this change.  Some more forcefully than others.

I don't see anyone against the change.

> How can a simple bug in gitmerge be a proof of anything (except that
> bugs happen)?

The existence of the special code for this in gitmerge is already proof
that this is suboptimal.  If it is buggy, that makes it worse of course.

But even if there are no bugs in gitmerge.el, today or in the future, we
still lose the ability to use "git blame" in etc/NEWS.NN for the
previous release on master.

And what's the upside?  None, AFAICT.

Instead of working against fundamental limitations in git, it is easy or
even trivial to completely side-step the issue.  AFAICT, the attached
patch fixes this on GNU/Linux, but I think you would need to do more on
operating systems without symlink support.  (There is obviously also
more stuff to do in gitmerge.el and the install step.  I didn't bother
for this quick proof-of-concept though.)

[-- Attachment #2: 0001-Move-etc-NEWS-to-etc-NEWS.NN.patch --]
[-- Type: text/x-diff, Size: 2185 bytes --]

From 64f7877d803d8ab7870469437bd6809e68142f42 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 10 Nov 2021 18:11:36 +0100
Subject: [PATCH] Move etc/NEWS to etc/NEWS.NN

* etc/NEWS: Move from here...
* etc/NEWS.29: ...to here.
* .gitignore: Ignore NEWS.
* autogen.sh: Symlink etc/NEWS to etc/NEWS.NN.
* src/callproc.c (init_callproc): Search for the etc/ directory based
on the "TODO" file instead of "NEWS".
---
 .gitignore            | 1 +
 autogen.sh            | 5 +++++
 etc/{NEWS => NEWS.29} | 0
 src/callproc.c        | 4 ++--
 4 files changed, 8 insertions(+), 2 deletions(-)
 rename etc/{NEWS => NEWS.29} (100%)

diff --git a/.gitignore b/.gitignore
index ea1662c9b8..c212340da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -264,6 +264,7 @@ doc/misc/cc-mode.ss
 doc/misc/modus-themes.texi
 doc/misc/org.texi
 etc/DOC
+etc/NEWS
 etc/refcards/emacsver.tex
 gnustmp*
 /info/
diff --git a/autogen.sh b/autogen.sh
index 531e5775f9..1112fadd63 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -140,6 +140,11 @@ do_git=
     test -r .git && do_git=true;;
 esac
 
+# Symlink NEWS
+if [ ! -e etc/NEWS ]; then
+    ln -s "$(ls -1 etc/NEWS.* | tail -1)" etc/NEWS
+fi
+
 # Generate Autoconf-related files, if requested.
 
 if $do_autoconf; then
diff --git a/etc/NEWS b/etc/NEWS.29
similarity index 100%
rename from etc/NEWS
rename to etc/NEWS.29
diff --git a/src/callproc.c b/src/callproc.c
index fa43f97384..f0354320f7 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1733,13 +1733,13 @@ init_callproc (void)
 
       srcdir = Fexpand_file_name (build_string ("../src/"), lispdir);
 
-      tem = Fexpand_file_name (build_string ("NEWS"), Vdata_directory);
+      tem = Fexpand_file_name (build_string ("TODO"), Vdata_directory);
       if (!NILP (Fequal (srcdir, Vinvocation_directory))
 	  || NILP (Ffile_exists_p (tem)) || !NILP (Vinstallation_directory))
 	{
 	  Lisp_Object newdir;
 	  newdir = Fexpand_file_name (build_string ("../etc/"), lispdir);
-	  tem = Fexpand_file_name (build_string ("NEWS"), newdir);
+	  tem = Fexpand_file_name (build_string ("TODO"), newdir);
 	  if (!NILP (Ffile_exists_p (tem)))
 	    Vdata_directory = newdir;
 	}
-- 
2.30.2

Re: master e714b31 3/6: Merge from origin/emacs-28

[Dmitry Gutov]

On 10.11.2021 22:36, Eli Zaretskii wrote:
>> But even if there are no bugs in gitmerge.el, today or in the future, we
>> still lose the ability to use "git blame" in etc/NEWS.NN for the
>> previous release on master.
> "git annotate" on NEWS is pretty meaningless anyway.  Stuff gets moved
> there too much for that to be useful.

I use that, from time to time.

For stuff that was moved (which happens, sure), we have 
'vc-annotate-revision-previous-to-line'.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Look closer, please.

It is up to you to produce evidence for your claims, or they will remain
unsubstantiated.

You claimed in the past that we can solve this and make everyone happy:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20403#33

Nothing has changed since then, besides your newly discovered opposition
to these changes.

>> The existence of the special code for this in gitmerge is already proof
>> that this is suboptimal.  If it is buggy, that makes it worse of course.
>
> Nonsense.  It just means we haven't yet got the full solution for
> that.

The better choice is to just not to create problems for ourselves in the
first place.

>> But even if there are no bugs in gitmerge.el, today or in the future, we
>> still lose the ability to use "git blame" in etc/NEWS.NN for the
>> previous release on master.
>
> "git annotate" on NEWS is pretty meaningless anyway.  Stuff gets moved
> there too much for that to be useful.

Some posters on this mailing list *do* use it (me included):

    "I use VC archeology on NEWS all the time.  It is handy when I need to
    know who and when added some new feature."

    https://lists.gnu.org/archive/html/emacs-devel/2021-09/msg00534.html

>> And what's the upside?  None, AFAICT.
>
> You are biased, so you only see the side that suits you.

That is just a run-of-the-mill ad-hominem.  If you disagree, feel free
to present substantial arguments instead.  I see no serious arguments so
far, yet you claim to be the one that is "unbiased".

> The upside is that we are using this for a long time, and any problems
> we see now are minor.

We have also had issues with it for a long time.  I have already
provided the evidence to back that claim up, but here's some more:

    "At present, emacs26:etc/NEWS has to get merged to master:etc/NEWS.26.
    This is a PITA at every single merge.

    "If the file was already called NEWS.26 on both branches,
    all these merge problems would go away."

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20403#30

Re: master e714b31 3/6: Merge from origin/emacs-28

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I vote +1 on the suggestion to just start using etc/NEWS.29

I'd be fine with that -- I don't see any significant downsides.  And in
addition to avoiding the merging problems, it'd help a bit with the VC
history of the NEWS.x file itself (it can sometimes be a challenge to
try to see which change went with which NEWS entry because of the way
the history if the NEWS file goes back to 1999).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master e714b31 3/6: Merge from origin/emacs-28

[Michael Albinus]

Stefan Kangas <stefankangas@gmail.com> writes:

> Let's count heads: Robert Pluim, Michael Albinus, Stefan Monnier, Stefan
> Kangas, Glenn Morris, Juri Linkov have AFAICT all come out in support of
> this change.  Some more forcefully than others.
>
> I don't see anyone against the change.

FTR, I'm rather neutral these days.

Best regards, Michael.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I vote +1 on the suggestion to just start using etc/NEWS.29
>
> I'd be fine with that -- I don't see any significant downsides.  And in
> addition to avoiding the merging problems, it'd help a bit with the VC
> history of the NEWS.x file itself (it can sometimes be a challenge to
> try to see which change went with which NEWS entry because of the way
> the history if the NEWS file goes back to 1999).

How about the attached patch?

[-- Attachment #2: 0001-Move-etc-NEWS-to-etc-NEWS.NN.patch --]
[-- Type: text/x-diff, Size: 5603 bytes --]

From e6b92a41ae6f0233baa0910a8eb24706650700cb Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Wed, 10 Nov 2021 18:11:36 +0100
Subject: [PATCH] Move etc/NEWS to etc/NEWS.NN

* etc/NEWS: Move from here...
* etc/NEWS.29: ...to here.
* .gitignore: Ignore etc/NEWS.
* autogen.sh: Symlink etc/NEWS to etc/NEWS.NN on GNU-like machines.
* Makefile.in (install-arch-indep): Move etc/NEWS.NN to etc/NEWS.
(etc-news): New phony target.
(all): Depend on 'etc-news'.
(maintainer-clean): Delete etc/NEWS.
* lisp/help.el (view-emacs-news): Fall back to NEWS.NN if NEWS is
missing.
* src/callproc.c (init_callproc): Search for the etc/ directory based
on the "TODO" file instead of "NEWS".
---
 .gitignore            |  1 +
 Makefile.in           | 16 ++++++++++++++--
 autogen.sh            | 11 +++++++++++
 etc/{NEWS => NEWS.29} |  0
 lisp/help.el          | 21 +++++++++++++++------
 src/callproc.c        |  4 ++--
 6 files changed, 43 insertions(+), 10 deletions(-)
 rename etc/{NEWS => NEWS.29} (100%)

diff --git a/.gitignore b/.gitignore
index ea1662c9b8..c212340da5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -264,6 +264,7 @@ doc/misc/cc-mode.ss
 doc/misc/modus-themes.texi
 doc/misc/org.texi
 etc/DOC
+etc/NEWS
 etc/refcards/emacsver.tex
 gnustmp*
 /info/
diff --git a/Makefile.in b/Makefile.in
index ccb5d93f2f..3e00b099af 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -343,9 +343,9 @@ BIN_DESTDIR=
 ELN_DESTDIR = ${ns_applibdir}/
 endif
 
-all: ${SUBDIR} info
+all: ${SUBDIR} etc-news info
 
-.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver
+.PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver etc-news
 
 # If configure were to just generate emacsver.tex from emacsver.tex.in
 # in the normal way, the timestamp of emacsver.tex would always be
@@ -358,6 +358,13 @@ etc-emacsver:
 	  ${srcdir}/build-aux/move-if-change emacsver.tex.$$$$ \
 	  ${srcdir}/etc/refcards/emacsver.tex
 
+# Do nothing on MS-Windows, as there is no support for symlinks.
+etc-news:
+ifeq (,$(filter cygwin mingw32,$(SYSTEM_TYPE)))
+	majorversion=`echo ${version} | sed 's/\..*//'`; \
+	ln -sf "NEWS.$${majorversion}" etc/NEWS
+endif
+
 # The shared gamedir name as a C string literal, or a null ptr if not in use.
 PATH_GAME = $(if $(use_gamedir),"$(gamedir)",((char const *) 0))
 
@@ -643,6 +650,10 @@ install-arch-indep:
 	  ${write_subdir}
 	subdir="$(DESTDIR)${datadir}/emacs/site-lisp" ; \
 	  ${write_subdir} || true
+	cd "$(DESTDIR)${etcdir}"; \
+	rm -f NEWS; \
+	majorversion=`echo ${version} | sed 's/\..*//'`; \
+	mv "NEWS.$${majorversion}" NEWS
 	[ -z "${GZIP_PROG}" ] || { \
 	  echo "Compressing *.el etc. ..." && \
 	  cd "$(DESTDIR)${lispdir}" && \
@@ -964,6 +975,7 @@ top_maintainer_clean=
 maintainer-clean: $(distclean_dirs:=_maintainer-clean)
 	rm -rf ${srcdir}/info
 	rm -f ${srcdir}/etc/refcards/emacsver.tex
+	rm -f ${srcdir}/etc/NEWS
 	${top_maintainer_clean}
 
 ### This doesn't actually appear in the coding standards, but Karl
diff --git a/autogen.sh b/autogen.sh
index 531e5775f9..b55592a902 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -140,6 +140,17 @@ do_git=
     test -r .git && do_git=true;;
 esac
 
+# Symlink NEWS
+newsfile="$(cd etc; ls -1 NEWS.* | tail -1)"
+rm -f etc/NEWS
+case "$(uname -s)" in
+    CYGWIN*) ;;
+    MINGW*) ;;
+    *) if [ ! -e etc/NEWS ]; then
+           ln -sf "$newsfile" etc/NEWS
+       fi ;;
+esac
+
 # Generate Autoconf-related files, if requested.
 
 if $do_autoconf; then
diff --git a/etc/NEWS b/etc/NEWS.29
similarity index 100%
rename from etc/NEWS
rename to etc/NEWS.29
diff --git a/lisp/help.el b/lisp/help.el
index 4470e6baaa..4089ac7ea3 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -443,12 +443,21 @@ view-emacs-news
   (let* ((vn (if (stringp version)
 		 (string-to-number version)
 	       version))
-	 (file (cond
-		((>= vn emacs-major-version) "NEWS")
-		((< vn 18) "NEWS.1-17")
-		(t (format "NEWS.%d" vn))))
-	 res)
-    (view-file (expand-file-name file data-directory))
+         (file (expand-file-name
+                (cond
+                 ((>= vn emacs-major-version) "NEWS")
+                 ((< vn 18) "NEWS.1-17")
+                 (t (format "NEWS.%d" vn)))
+                data-directory))
+         ;; Find a file even if etc/NEWS is missing.
+         (realfile (or (and (string-equal (file-name-base file) "NEWS")
+                            (not (file-exists-p file))
+                            (expand-file-name
+                             (format "NEWS.%d" vn)
+                             (file-name-directory file)))
+                       file))
+         res)
+    (view-file realfile)
     (widen)
     (goto-char (point-min))
     (when (stringp version)
diff --git a/src/callproc.c b/src/callproc.c
index c949fff4db..b82f4a225b 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -1922,13 +1922,13 @@ init_callproc (void)
 
       srcdir = Fexpand_file_name (build_string ("../src/"), lispdir);
 
-      tem = Fexpand_file_name (build_string ("NEWS"), Vdata_directory);
+      tem = Fexpand_file_name (build_string ("TODO"), Vdata_directory);
       if (!NILP (Fequal (srcdir, Vinvocation_directory))
 	  || NILP (Ffile_exists_p (tem)) || !NILP (Vinstallation_directory))
 	{
 	  Lisp_Object newdir;
 	  newdir = Fexpand_file_name (build_string ("../etc/"), lispdir);
-	  tem = Fexpand_file_name (build_string ("NEWS"), newdir);
+	  tem = Fexpand_file_name (build_string ("TODO"), newdir);
 	  if (!NILP (Ffile_exists_p (tem)))
 	    Vdata_directory = newdir;
 	}
-- 
2.30.2

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

On November 17, 2021 6:04:21 AM GMT+02:00, Stefan Kangas <stefankangas@gmail.com> wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Robert Pluim <rpluim@gmail.com> writes:
> >
> >> I vote +1 on the suggestion to just start using etc/NEWS.29
> >
> > I'd be fine with that -- I don't see any significant downsides.  And in
> > addition to avoiding the merging problems, it'd help a bit with the VC
> > history of the NEWS.x file itself (it can sometimes be a challenge to
> > try to see which change went with which NEWS entry because of the way
> > the history if the NEWS file goes back to 1999).
> 
> How about the attached patch?

I already said that I object to making this kind of change, so please don't do that.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> How about the attached patch?
>
> I already said that I object to making this kind of change, so please
> don't do that.

Well, since Stefan is the one that's doing the merges now, his opinion
should carry some weight.

Changing the name to EMACS.29 makes things easier when merging, and...
I don't really see any significant downsides.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

On November 17, 2021 9:56:49 AM GMT+02:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> How about the attached patch?
> >
> > I already said that I object to making this kind of change, so please
> > don't do that.
> 
> Well, since Stefan is the one that's doing the merges now, his opinion
> should carry some weight.

Stefan's opinions do carry some weight, and not just some.  But in this case, I still disagree with making the proposed changes.  And if that means I will have to do the merges, then so be it.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 17 Nov 2021 08:56:49 +0100
> Cc: Robert Pluim <rpluim@gmail.com>, Stefan Kangas <stefankangas@gmail.com>,
>  emacs-devel@gnu.org
> 
> I don't really see any significant downsides.

I tried to point out the downsides: the change is not really trivial,
and therefore will have fallout, as always happens with such changes.
And we will have to deal with that fallout.  Of course, since we are
always overly optimistic and hope there will be no unintended
consequences, we always tend to underestimate the downsides.

For non-problems such as this one, changes like this are just waste of
time and energy.  VCS is a tool, a means to an end; let's not make
changes in our code and create opportunity for subtle bugs just
because people rarely make VCS-related mistakes.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I tried to point out the downsides: the change is not really trivial,
> and therefore will have fallout, as always happens with such changes.
> And we will have to deal with that fallout.  Of course, since we are
> always overly optimistic and hope there will be no unintended
> consequences, we always tend to underestimate the downsides.

I understand your general concern, as with any code change, but I don't
agree with the conclusion that we must not make this particular change.

I expect that there will be fallout only in code that assumes that an
etc/NEWS file exists.  (Creating the symlink on GNU/Linux is mostly just
convenience and not a proper solution, IMO.)

I think I covered most such cases in my patch, but of course I might
have missed a few.  Having reviewed many (most? all?) such cases in our
tree though, I very seriously doubt that any of it will be hard to
change.  It is a trivial case of: point it to NEWS.NN if NEWS doesn't
exist.  You can see some examples in my latest patch.  Any such changes
should be small and localized.

Once we cut the emacs-29 branch, gitmerge.el may or may not need more
changes.  I think there is plenty of time to test it though, and I
intend to do so if and when this lands on master.  From my cursory
reading, this will take at most a small amount of effort, as it just
involves skipping some special handling that is no longer needed.

> For non-problems such as this one, changes like this are just waste of
> time and energy.  VCS is a tool, a means to an end; let's not make
> changes in our code and create opportunity for subtle bugs just
> because people rarely make VCS-related mistakes.

This is just one thread of many that we have had about the issues this
has caused over the years.  We would arrive at the exact same conclusion
whether or not this latest incident had happened or not.  In fact, we
discussed it just the other week as well, in the thread where Glenn said
he won't be doing the merges.  Sweeping it under the rug by calling it a
"non-problem" is no solution at all.

The real reasons for wanting to fix this real problem are:

- It destroys our git history for the NEWS.NN file every time we cut a
  release branch.

- It makes merging hard and error-prone.

- It really is an abuse of git when we could instead use it to our
  advantage.  (There is no need to maintain custom code for a "merge"
  that still leaves history broken when we could just let git do it.)

I propose that instead of fixing bugs in a fundamentally broken and
wrong solution, we just do the right thing.  We will have fewer bugs to
fix in the long run, and there are important advantages.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 17 Nov 2021 17:59:48 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I tried to point out the downsides: the change is not really trivial,
> > and therefore will have fallout, as always happens with such changes.
> > And we will have to deal with that fallout.  Of course, since we are
> > always overly optimistic and hope there will be no unintended
> > consequences, we always tend to underestimate the downsides.
> 
> I understand your general concern, as with any code change, but I don't
> agree with the conclusion that we must not make this particular change.

Unfortunately, you don't say anything to explain why you "don't agree
with the conclusion", although you "understand my general concern".
Without explaining that, we are just reiterating the same arguments
over and over again.

This is a project-management issue, it has to do with a decision
whether a particular problem justifies the risks of a proposed
solution.  It's fundamentally a judgment call, and my judgment is that
the problem, such as it is, doesn't justify the risks.  If you want to
try to convince me to change my mind, you must provide arguments on
this level.  It isn't easy, because such judgments are very objective
and depend on our experiences, which are probably very different.  But
that's the only way of having a meaningful discussion of this issue,
and just repeating your disagreement in the face of my concerns
doesn't add anything useful to the discussion and certainly doesn't
give me anything to think about that I didn't already consider.

> I expect that there will be fallout only in code that assumes that an
> etc/NEWS file exists.  (Creating the symlink on GNU/Linux is mostly just
> convenience and not a proper solution, IMO.)
> 
> I think I covered most such cases in my patch, but of course I might
> have missed a few.  Having reviewed many (most? all?) such cases in our
> tree though, I very seriously doubt that any of it will be hard to
> change.

Like I said: we are always overly-optimistic about our abilities to
expect the unexpected.  We've been proven wrong many times, but we
still insist on hoping that this won't happen the next time.  How do
you reconcile these two and arrive at the (optimistic) conclusion that
this time will be different?  You don't say.

> It is a trivial case of: point it to NEWS.NN if NEWS doesn't
> exist.  You can see some examples in my latest patch.  Any such changes
> should be small and localized.

Yes.  Unless the unintended happens.  We are talking about risk
management, not about the specific technical solution you propose.
The useful arguments should compare the risks in the current situation
vs the risks of what could happen if we install your changes.

> > For non-problems such as this one, changes like this are just waste of
> > time and energy.  VCS is a tool, a means to an end; let's not make
> > changes in our code and create opportunity for subtle bugs just
> > because people rarely make VCS-related mistakes.
> 
> This is just one thread of many that we have had about the issues this
> has caused over the years.  We would arrive at the exact same conclusion
> whether or not this latest incident had happened or not.  In fact, we
> discussed it just the other week as well, in the thread where Glenn said
> he won't be doing the merges.  Sweeping it under the rug by calling it a
> "non-problem" is no solution at all.

What problem are you talking about?  Glenn wrote that code when he was
the only person who did the merges regularly, so it is a small wonder
that some of that doesn't work on other systems, especially on mine.
The reasons for that were identified and I have a local fix for it,
which I hope to test when I get the chance (some merge where NEWS is
involved).  That's it.  Following your optimism, I can likely say that
this problem is solved for good, and will never happen again.  So why
keep insisting that it exists?

IOW, what we had was a (relatively minor) fallout from passing the
responsibilities from one person to others.  This is behind us, so any
changes at this point look entirely unnecessary to me.

> The real reasons for wanting to fix this real problem are:
> 
> - It destroys our git history for the NEWS.NN file every time we cut a
>   release branch.
> 
> - It makes merging hard and error-prone.
> 
> - It really is an abuse of git when we could instead use it to our
>   advantage.  (There is no need to maintain custom code for a "merge"
>   that still leaves history broken when we could just let git do it.)
> 
> I propose that instead of fixing bugs in a fundamentally broken and
> wrong solution, we just do the right thing.  We will have fewer bugs to
> fix in the long run, and there are important advantages.

We have been over this already.  You are repeating arguments that were
voiced before, and I already considered all of those arguments before
I made up my mind.  How can I explain to you that reiterating them
will not change anything?  I tried explaining that many times in many
different ways, and I still fail to get my point through.  I tried
above one more time, in the(optimistic) hope that this time I will
succeed ;-)

Re: master e714b31 3/6: Merge from origin/emacs-28

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> We have been over this already.  You are repeating arguments that were
> voiced before, and I already considered all of those arguments before
> I made up my mind.  How can I explain to you that reiterating them
> will not change anything?  I tried explaining that many times in many
> different ways, and I still fail to get my point through.  I tried
> above one more time, in the(optimistic) hope that this time I will
> succeed ;-)

However, I can't see that you've really refuted Stefan's points here --
merging NEWS is a real problem, and Stefan's suggestions seem to fix
those issues.  The only downsides seems to be a nebulous "but it might
break something".  Which is true.  I think the advantages here far
outweigh the potential problems, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master e714b31 3/6: Merge from origin/emacs-28

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  rpluim@gmail.com,
>   emacs-devel@gnu.org
> Date: Thu, 18 Nov 2021 10:25:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We have been over this already.  You are repeating arguments that were
> > voiced before, and I already considered all of those arguments before
> > I made up my mind.  How can I explain to you that reiterating them
> > will not change anything?  I tried explaining that many times in many
> > different ways, and I still fail to get my point through.  I tried
> > above one more time, in the(optimistic) hope that this time I will
> > succeed ;-)
> 
> However, I can't see that you've really refuted Stefan's points here --
> merging NEWS is a real problem, and Stefan's suggestions seem to fix
> those issues.

There's nothing to fix, because the problem doesn't exist.  It
happened once on my machine, and that's it.

> The only downsides seems to be a nebulous "but it might break
> something".  Which is true.  I think the advantages here far
> outweigh the potential problems, though.

I disagree, as I already said numerous times.  I also tried to explain
why the arguments being brought up are not really relevant to the
reason why I object.

Re: master e714b31 3/6: Merge from origin/emacs-28

[Dmitry Gutov]

On 18.11.2021 14:10, Eli Zaretskii wrote:
> There's nothing to fix, because the problem doesn't exist.  It
> happened once on my machine, and that's it.

What about the semi-broken/destroyed Git history in files NEWS.NN?

We don't generally rename files gratuitously in this project for a reason.