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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 19 Apr 2023 17:23:19 +0100
> Cc: Dmitry Gutov <dmitry@gutov.dev>, rpluim@gmail.com, philipk@posteo.net, 
>       62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> 
> On Wed, Apr 19, 2023 at 5:10 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > But note that this is not what João is saying.  He says 1.14 will not
> > be in Emacs 29.1, period.  No matter how long I will drag the pretest.
> > He certainly doesn't want to invest the effort of making Eglot 1.14
> > less dependent on latest changes in other packages, so as to make sure
> > we could drop Eglot 1.14 into Emacs 29 without risking any problems
> > elsewhere.  And that more or less seals the issue, effectively setting
> > your N to infinity.
> 
> This is extremely odd for me.  Weren't you the one very, very sternly
> asking for almost _no_ changes to go into Elisp code of the Emacs 29
> now that it is in pretest.  And now you're liberally and casually
> suggesting way-over-last minute changes and work to go into that same
> version?

I'm talking only about Eglot, not in general.  I believe I've stressed
that point already.  So what I said or did or asked to do regarding
other packages or other places in Emacs is not necessarily relevant
for this discussion.  The decisions about these issues are always on a
case by case basis, so you cannot compare different cases and expect
them to yield the same decisions.

> This just doesn't make any sense to me.  Can't you understand that other
> maintainers also value stability for their packages?

Of course I can.  But once again: if Eglot 1.14 is not stable enough,
then why do we recommend users of Emacs 29 to update their bundled
Eglot to v1.14?  This is inconsistent: if 1.14 is not stable enough to
be in Emacs 29, we should only recommend it for users of Emacs 30.

I already explained this inconsistency more than once.  Why do you
keep bringing it up time and again?  You might disagree, but why do
you insist that I accept what I perceive as inconsistent logic?  Just
let it go and accept that we disagree about this.

> It's certainly NOT about "not wanting to invest the effort".  That effort
> would amount to forking Eglot in its feature set so that effort would be
> a disservice to everybody.

No, it doesn't require any forks.  It requires more cautious
introduction of new features into Eglot on master.  And yes, it's
extra effort.  But IMNSHO, users will benefit, so in my book it's
worth it.