From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Wed, 19 Apr 2023 16:35:46 +0300 Message-ID: <834jpc805p.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <875y9yfxrr.fsf@gmail.com> <87y1muefks.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <06d29dbd-0b33-8698-bcb8-c89368612f54@gutov.dev> <252e77fb-9657-a5be-2e86-234f7b05d162@gutov.dev> <83edog84cm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14611"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62720@debbugs.gnu.org, rpluim@gmail.com, philipk@posteo.net, dmitry@gutov.dev, monnier@iro.umontreal.ca, larsi@gnus.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 19 15:36:14 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pp7yo-0003eF-HH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Apr 2023 15:36:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pp7yf-0001Pd-T4; Wed, 19 Apr 2023 09:36:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pp7yd-0001LF-Ef for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 09:36:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pp7yc-00061M-8j for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 09:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pp7yb-0001N2-KN for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 09:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Apr 2023 13:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.16819113515252 (code B ref 62720); Wed, 19 Apr 2023 13:36:01 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 19 Apr 2023 13:35:51 +0000 Original-Received: from localhost ([127.0.0.1]:33089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pp7yQ-0001Md-M6 for submit@debbugs.gnu.org; Wed, 19 Apr 2023 09:35:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pp7yK-0001ML-Og for 62720@debbugs.gnu.org; Wed, 19 Apr 2023 09:35:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pp7yE-0005cj-BJ; Wed, 19 Apr 2023 09:35:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=D3U2CYlwXc8j+nWXpy2CV+kUc/S6pQBWIYkz8+KEhCw=; b=B4DG9S0Cwvb4+ugItL1u 7+/xDMKyYNSVEdTi57GVb9s9qOlWPBwZfOyAxYhs9Zcv3C9+MTPFwxRL29k/QVuaZrlpW+UqC2re0 1BnKDykotd/J5kwvwvWvKWAOFq7o5Hcu2InU+peoAQ7XeEh0VTq/uQXgpZRAYCfgdwjrOtcqdmDJy pFHxE6c9gexbuhnNZFA0iat/kLPu2hYdmzaRCkkJfBRee8+oY5THwD56S/gIZ7M84BulYH6/c4g7w KLGpdMuDPJJFy2EMsMBb5YrDEye62inSmx7OhenqZx8aPigqVoJh0rJkJKwJ8GNxK9sysFMAiBOcP YieXCj8iOmWvwA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pp7yC-0004H9-Vd; Wed, 19 Apr 2023 09:35:37 -0400 In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Wed, 19 Apr 2023 14:04:10 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260270 Archived-At: > From: João Távora > Date: Wed, 19 Apr 2023 14:04:10 +0100 > Cc: Dmitry Gutov , rpluim@gmail.com, philipk@posteo.net, > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > > Eli, do you want Eglot 1.14 (or 1.15, or 1.16 or whatever version > is the latest Eglot release "several weeks" from now) to be in Emacs 29? What I want in Emacs 29.1 (and any future release of Emacs) is the latest version of Eglot that you, as Eglot developer, consider stable enough to recommend to users of a stable Emacs. Which version is that is your decision. But to make sense to me, the decision you make should be consistent: if a version X.Y of Eglot is "stable enough" for you to recommend that users of Emacs 29.n upgrade to it, then that version X.Y can be part of Emacs 29.n. (Of course, if you decided that X.Y is stable enough _after_ Emacs 29.n was released, then X.Y will be able to become part of Emacs only in Emacs 29.n+1 and later.) I say above "to make sense to me", and I mean that, and only that. That is, you _can_ decide that you don't agree with my definition of consistency, and therefore Eglot X.Y will be recommended to users of Emacs 29.n, but at the same time you don't want it to be in Emacs 29.n; such a decision will not "make sense to me", but we will still act according to your decision in this matter. I hope I clarified my position in this regard. And before you draw too far-fetched conclusions from the above: I'm saying this about Eglot, and only about Eglot. Similar decisions about other packages, and the conditions for including those other packages in a stable Emacs versions, could very well be different. > 1. Bundle Eglot 1.1x with Emacs 29 and all its up-to-date dependencies, so > that, right at the moment of the Emacs 29 release, Eglot would function > exactly the same on Emacs 28 + package-install. That is probably not acceptable, although I'd need to know exactly which versions of what other packages need to be imported into the emacs-29 branch, to give a definitive answer. > 2. Bundle a "Frankenglot" with Emacs 29 that has all the > lisp/progmodes/eglot.el code of the future Eglot version, advertises > itself as Eglot 1.1x, probably doesn't break, but does _not_ provide > the same experience as Emacs 28 + package-install > > Both options are bad, IMO, but 2 is worse. I don't see why option 2 would be bad, let alone worse. See below. > The first reason that both options are bad is that you're discarding > whatever value the pretest phase brings to the stability of Eglot's code. Eglot itself isn't my problem. My problem is the other packages that upgrading Eglot, per option 1 above, will require to update: those other packages usually affect much more than just Eglot, and therefore bringing their potentially less stable code into emacs-29 might break much more than just Eglot. > Eglot, being a part of Emacs the Emacs code base, benefits from the same > testing all its code does. You're discarding that value, and I think > it's bad, because the pretest is supposedly there for a good reason. A bug in > Eglot 1.1x will just escape us and there's no time to fix it. Please leave this consideration to me, it is exactly the kind of judgment call I make every several days when someone asks whether a particular change is OK for the release branch. And in the case of Eglot I already said that IMO we should include in Emacs 29.1 the latest stable version of Eglot, thus my decision about that was already made in favor of upgrading Eglot on emacs-29. But I won't insist if you are uncomfortable with that. > The second reason only applies to option 2. It would completely confuse > users. A user running Emacs 28 would see a much better 1.1x than > the 1.1x bundled in Emacs 29. No, users of Emacs 28 who installed the latest stable Eglot from ELPA should see almost the same version of Eglot as users of Emacs 29.1 if that will come with the same stable Eglot. Unless you intend to somehow degenerate important parts of Eglot in what you call "Frankenglot", whatever that means. My interpretation of option 2 is that we get a newer Eglot (1.14 or 1.15, whichever you decide is stable enough) with various minor fallbacks intended to work around the fact that dependency packages are not necessarily at their versions for which Eglot 1.14/1.15 was designed to work, if the versions of those dependencies in Emacs 29.1 are older. That is, 1.14/1.15 without the mandatory requirement o upgrade any other package already in Emacs. If that is not what you mean, then perhaps consider this as option 3, which is the one that makes the most sense to me, and if possible and agreed upon, will be accepted into emacs-29.