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: Sat, 15 Apr 2023 12:03:06 +0300 Message-ID: <835y9xecvp.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <875ya1tdwf.fsf@posteo.net> <83edop6sdy.fsf@gnu.org> <831qkp6o0i.fsf@gnu.org> <83wn2h5825.fsf@gnu.org> <87wn2gkhzr.fsf@posteo.net> <83cz485oxi.fsf@gnu.org> <87leiwdyff.fsf@posteo.net> <834jpk5hih.fsf@gnu.org> <871qkom3fj.fsf@posteo.net> <83mt3b4yfc.fsf@gnu.org> <87edonlsxi.fsf@posteo.net> <83jzyf4vzb.fsf@gnu.org> <871qknllkj.fsf@posteo.net> <83fs934pjf.fsf@gnu.org> <87wn2fk47y.fsf@posteo.net> <83sfd2g2ek.fsf@gnu.org> <875y9yfxrr.fsf@gmail.com> <87y1muefks.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.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="31760"; 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 Sat Apr 15 11:04:17 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 1pnbpR-00082v-GT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Apr 2023 11:04:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnbpE-0004lN-75; Sat, 15 Apr 2023 05:04:04 -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 1pnbpC-0004ks-KP for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2023 05:04:02 -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 1pnbpC-0006kF-By for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2023 05:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pnbpB-0003ek-VB for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2023 05:04: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: Sat, 15 Apr 2023 09:04: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.168154939813994 (code B ref 62720); Sat, 15 Apr 2023 09:04:01 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 15 Apr 2023 09:03:18 +0000 Original-Received: from localhost ([127.0.0.1]:48218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnboT-0003de-F5 for submit@debbugs.gnu.org; Sat, 15 Apr 2023 05:03:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnboR-0003dQ-3f for 62720@debbugs.gnu.org; Sat, 15 Apr 2023 05:03:16 -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 1pnboK-0006Wl-83; Sat, 15 Apr 2023 05:03:08 -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=XaWMEh8Fynen7/Vw4Ug25YPyZKnocxXQLp+WbUrPf0w=; b=P0oV0vWOYJIqd8eRIHH2 4gVRkZVHnkGLOiO9Tq6VG6dK5o6EbzhGAgWSGxRfGaNNscvS6cwqQXwTmiTC85+/6zw2MoIpwuUze XIw+tf3vk6b+pFEF2kHx1e4VaebPH9utgGuGSADiK4EFIf411iW67shhSOI6NXniFfy9bAkg40fHe VuapZOOqH0CNuT2r7MOVy6uc0OA3zPyNyRWAnXhYX96FFdkIFnPVLuFhMs+TP5bGZf5PsOi7G7wGR lhELcYnG3sBfK75HSUKWJxbh0RfOiNw3vuAFVGbfF9NyB+sbHPX3QYs/IrEUzFUfLVHKXWMnw5rqp Bc/1stgDik6dbA==; 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 1pnboI-00005T-Vh; Sat, 15 Apr 2023 05:03:07 -0400 In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Fri, 14 Apr 2023 20:46:02 +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:260006 Archived-At: > From: João Távora > Date: Fri, 14 Apr 2023 20:46:02 +0100 > Cc: dmitry@gutov.dev, rpluim@gmail.com, philipk@posteo.net, > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > > On Fri, Apr 14, 2023 at 8:28 PM Eli Zaretskii wrote: > > > > > From: João Távora > > > Date: Fri, 14 Apr 2023 20:20:20 +0100 > > > Cc: dmitry@gutov.dev, rpluim@gmail.com, philipk@posteo.net, > > > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > > > > > > On Fri, Apr 14, 2023 at 7:51 PM Eli Zaretskii wrote: > > > > > > The Eglot release 1.14 is not as stable as 1.12.29. It has new features. > > > Also a recent bugfix in commit a74403adda0 is quite complex and > > > I'm cautiously waiting for feedback. Other simple bugfixes have > > > been backported. > > > > So you don't recommend that users who want a stable Eglot upgrade to > > 1.14? > > Depends on how "stable" they want it and how badly they want new > features. You are dodging the question, which is unfortunate. It is IMO an important question, much more general and important than this tempest-in-a-teapot issue we are discussing here. We will need to revisit this question seriously if we ever succeed in removing 'core' packages from emacs.git and bundling them with release tarballs. At that time, we will need clear-cut criteria for how to select the version of a package that is the most suitable one to go into the tarball. And that in turn will require the developers of each such package to seriously address the questions I've asked: what are the criteria for considering a package version "stable", and how is that communicated via version numbers and/or repository branches. For example, Org has that encoded in its branches, so that the latest changes from its stable branch are routinely merged into the stable branch of Emacs, and the latest code from that branch will be in the Emacs release tarball. Based on your answer, it sounds like Eglot users are on their own in this aspect: they have no real guidance from you which version is currently considered "stable". > > If so, why is it a problem that package-install by default > > doesn't update built-in packages? Users who want the cutting edge of > > Eglot, and don't mind some instability, can always switch to the > > master branch of Emacs, where we are free to change package-install to > > upgrade core packages by default. > > Users don't just switch to the master branch of Emacs. Many just > can't because of enterprise complications, or just difficulty of compilation. > I've worked in companies using Emacs (some of them exclusively!!) for 20 > years. Most users are two, sometimes, three Emacs releases behind. > They are not remotely interested in updating. "IT doesn't like it". > "It's not the official". "This one is just fine". > > But if a colleague goes to their workstation and shows them > M-x package-install RET very-fancy-nice-thing or sends them a > super-fancy init.el they will take it no problem, and buy you > coffee and rave about it. I can't be the only one who has > experienced this :-) I have no doubt there are such cases. But I very much doubt they are the majority. Whatever we decide, it is clear that some use cases will want a different behavior. The issue discussed here is what should be the default behavior, and whether the default behavior of Emacs 29.1 would be wrong for most users of Eglot and of other core packages. To reiterate: I think each release of Emacs should ship with the latest stable version of each core package. If this is the case, the need to upgrade core packages via package.el is not very important for the majority of our users who prefer to use a stable Emacs. Thus, the arguments you present emphasize the needs of the minority, and therefore I don't consider them strong enough to invalidate the compromise solution to which we are converging. > > > But if someone types M-x install-something they should get what > > > they ask for. If they want to be 100% safe, they just shouldn't > > > invoke commands that download, compile and evaluate code. > > > > The logic should be consistent. Emacs 29 is the stable branch of > > Emacs, so it should come with the latest stable Eglot. If that is > > Eglot 1.12.29, then the fact that package-install won't upgrade it to > > 1.14 is consistent with the stability of Eglot's versions. If, OTOH, > > you think that it's imperative to allow _all_ users of Eglot with > > Emacs 29 to upgrade to Eglot 1.14 (and 1.15, 1.16, etc., when those > > become available), then we should release Emacs 29 with 1.14. > > I think it's imperative to _allow_ -- as you say -- and also and > to _make easy_. "C-u M-x package-install" is easy enough. > More importantly, and to the point, to _make it as easy as it was in > Emacs 26, 27 and 28_. That's an impractical request, one that most probably prefers Eglot users (and only part of them at that) to those of other core packages. We must think about all the users, not just users of Eglot. The price of adaptation to the fact that Eglot is now a core package, while it is not nil, is not high. So once again, this solution is IMO a reasonable compromise, given the constraints. > > Philip presented such a safe modification, and we are in the final > > stages of discussing its details, before it will be installed. So > > yes, it is possible. > > As I've explained to Philip, the big drawback of that -- undoubtedly > safe -- modification is that it is not compatible to user's > configurations that have a (use-package 'eglot) or a > (package-install 'eglot) in them. That is not a problem serious enough to invalidate the solution. We can, for example, mention the change in NEWS, to alleviate some of the costs.