GNU bug report logs - #62720
29.0.60; Not easy at all to upgrade :core packages like Eglot

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 62720 <at> debbugs.gnu.org, rpluim <at> gmail.com, philipk <at> posteo.net, joaotavora <at> gmail.com, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 19 Apr 2023 15:05:13 +0300

> Date: Wed, 19 Apr 2023 00:20:21 +0300
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, philipk <at> posteo.net,
>  62720 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 19/04/2023 00:15, João Távora wrote:
> >> Aha, so the :echo thingy made it possible. Gotcha.
> > Right, which is also the reason it makes even_less_  sense to bring Eglot
> > 1.15 into Emacs 29_without_  ElDoc (I hope that plan is now completely off
> > the table).
> 
> Eh, sure.

It isn't my call in this case, but FWIW: I still have no idea why
wouldn't we want Eglot 1.14 or 1.15 to be in Emacs 29.1.  I didn't
hear any serious argument against doing that; every reason that was
raised was almost immediately explained away as not being a hard
limitation.

And mind you: Emacs 29.1 will not be released tomorrow or the day
after.  We still have at least several weeks till then, with at least
one more pretest.  So the decision whether to import a newer Eglot
into the release branch doesn't have to be today.  However, the
argument against updating Eglot on the release branch, such as they
were, are of some vaguely "fundamental" nature, so I'm not sure a few
more weeks of time will change the decision.  No one said something
like "if Emacs 29.1 were to be released in NN weeks or more, it would
be okay to update Eglot on the release branch."  But then I already
admitted to not understanding those reasons, so maybe I'm missing
something here.

So there you are.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.