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

[Eli Zaretskii]

> Date: Wed, 19 Apr 2023 18:48:00 +0300
> Cc: joaotavora@gmail.com, rpluim@gmail.com, philipk@posteo.net,
>  62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > 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.
> 
> Let's imagine I was making this choice.
> 
> I would include (or propose for inclusion) Eglot 1.x.y in Emacs 29 only 
> N weeks after it has been tagged on master and thus published to ELPA, 
> on the condition that no major bugs have been discovered in the meantime 
> that required major reworks (because any bugfix would reset the timer to 
> L weeks where L < N, but a major change would reset it to N weeks 
> again). That would be the general guideline. Add to that the 
> maintainer's best judgment, who would be able to reduce or extend these 
> periods on case by case basis as well, according to the changes that 
> went into every release.
> 
> To answer the original question: N weeks still haven't passed (I guess) 
> since 1.15 was tagged, so we don't quite know whether it's acceptable 
> for emacs-29.

That is fine with me, assuming N has some reasonable value.  It means
I could ask you again before the next pretest, and then again before
RC, and perhaps you'd then agree to import a newer Eglot.

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.