From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Wed, 19 Apr 2023 01:10:56 +0300 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <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> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8830"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 19 00:12:05 2023 Return-path: Envelope-to: ged-emacs-devel@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 1potYR-00026Q-2U for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Apr 2023 00:12:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1potXa-000104-31; Tue, 18 Apr 2023 18:11:10 -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 1potXX-0000zb-Ug for emacs-devel@gnu.org; Tue, 18 Apr 2023 18:11:08 -0400 Original-Received: from new4-smtp.messagingengine.com ([66.111.4.230]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1potXS-0000gd-Mj; Tue, 18 Apr 2023 18:11:07 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 11612582530; Tue, 18 Apr 2023 18:11:01 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 18 Apr 2023 18:11:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1681855861; x=1681859461; bh=HScK3g/V2XIEuVcVqfMrbU6IjR/mD14zrlp QNcFEuiw=; b=sYrIuWPZnep0HHUCx2vraX7YCHfm6UX8zPB0RzDcdyEc+ZUXEJm IXzMWtIg3Brq5X/r10FBV+Z6j4Kvxiym5oKBAPfDwpqsz0fsiPin8JKxdXAJYOAa obVJ8ySqr+dubH36U63vIKOKRliIBnbkXNqDiMgJ0BbVBuvjOCFmWS3aOfKkRmNJ +6BchtnkEN2gSWrlZFZLICrUcClVM1LdYEmkpq6OPXlF7wcfCN4+no4jv7vKKXTZ 58GphrluV4125QNhw6vEBYicqyCBbPLPHuji//PuE4V9xG3ng/tFnfumYZGprAHb IqurDT4SBcTu1j4O9ck2zzh5BoQKqr8Bgfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1681855861; x=1681859461; bh=HScK3g/V2XIEuVcVqfMrbU6IjR/mD14zrlp QNcFEuiw=; b=bcK5fDH9enjsyZDLUSInwQgXZSMgfv4d9qtQooQ9fR9tP7yO3qA xwym8cjwLa3bbfDsmcMOuLTH0fwab4zWzgifSER0nt3blE6avxvpB3a15OJARrYK I1mp0VZd5vRFVz93DrrcZI3xDp7QwWa/ZvUzd2yjFWGUM627EM4kQcMM2Nk1RDtZ t5KLy93qyialnaZZsisy8AAIvOFw3Z6z+cbN1vEOi5Ig/66dSCiCdtHKaRyL0L8q zd2fC6XhQJnfQCUV0XgoysXX+BnenR29XS/krAHn5iPXRjns1qe3fhOd/44+Tjkb K4RtLbT8y4ClbzrwjZJSsIB1O82ASmqchPg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdelledgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 Apr 2023 18:10:59 -0400 (EDT) Content-Language: en-US In-Reply-To: <83r0sh8i1q.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.230; envelope-from=dmitry@gutov.dev; helo=new4-smtp.messagingengine.com X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.597, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305421 Archived-At: On 18/04/2023 15:57, Eli Zaretskii wrote: >>>> On 14/04/2023 22:28, Eli Zaretskii wrote: >>>>> 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. >>>> >>>> Was this question about stability only? >>> >>> It was about the criteria for which versions of core packages to ship >>> with a release. >> >> I don't think we can get a single set of criteria across core packages. > > We don't need to have just one set. Packages are different in both > their complexity, their dependence on other packages, and dependence > of other packages on them. So one set is unlikely to fit the bill, > indeed. > > But that doesn't mean we shouldn't have criteria at all. We should > strive to have a small number of them, and we should know which set is > applicable to which class of packages. It's a good question, but not a deciding one WRT what we should do with Eglot for Emacs 29, I think. I hope I'll be able to explain that below. > This will be one of the serious issues if we ever move to having some > packages only in elpa.git, and will then bundle them when preparing an > Emacs release tarball. It will be imperative to know at that time > which version/branch of each such package to take as part of preparing > a release. We must have a solution by then, so this is as good time > as any to start discussing the issue. Sure. Please keep in mind, however, that very few of external packages have separate branches for releases and development. I guess Org does, but I'm not sure if others exist. One of the reasons for that is that the ELPA repositories only package the very latest released version anyway and quickly delete the older ones. And package.el is the foremost distribution method for Elisp code. For :core package, we also have Emacs's own development and release branches. But only master branch has versioned releases cut from it. It's hard to say whether the time the code has spent in a given 'emacs-xy' branch brings maturity to it, and how much. So every time a new version if tagged, it's a value judgment on the part of the maintainer: whether enough time has passed since the most recent big feature was added, whether there were bug reports or not. The MELPA project has helped a lot with this over the years because it popularized snapshot versions. So when a package is feature on MELPA, the author could be fairly sure that a lot of users have downloaded the latest snapshot and gave it a try, and the lack of new reports means it's probably okay. MELPA has the problem that the "Stable" repository is not very popular, though. We here have it in the reverse: I'm not sure how many people make use of elpa-devel (GNU-devel ELPA). Probably not many. >> E.g. Org is developed externally, has its own community of significant >> size, and does split off release branches (with additional testing, I',m >> guessing). >> >> Eglot, OTOH, is developed only here, with no additional release workflow >> other than what MELPA/GNU ELPA historically provided: collect up some >> features/fixes, bump the Version header, and push a new release out to >> the users. The lack of extended testing period is made up for with the >> capability to push out a new fixed version overnight. That's why the >> difficulty in upgrading to the latest version (for Emacs 29 users) is >> going to hurt. > > If some core package is not tested enough before it gets a new > version, then why are we okay with telling users of a stable Emacs to > update the package willy-nilly as soon as another version is on ELPA? > Shouldn't we at least warn them, or, better, somehow indicate that > this version is not yet considered stable? I have a different answer from all that had been presented here: because the user can uninstall it. Uninstall any newer installed version and stay with that one that had been bundled with the Emacs release. As long as *that* one has been picked well enough to be stable, and can be reverted to, we can afford not to worry too much about the user installing another version. It's like reverting to a more stable distribution channel, to use the analogy from the bug discussion. > IOW, shouldn't packages have some "stability gradation" that is > visible when users look at the list of packages via package.el? > Shouldn't we allow users to tell package.el which stability they want > to download, so that unstable packages don't inadvertently get > installed and mess up their production environment? We have elpa and elpa-devel. The latter is "explicitly unstable" and the former is "checkpoint releases". Neither keeps the previous versions around, so it's not like the user at any point could make a choice to install a minor version update instead of going up a full major version. The only choice is to update to the latest, or not (by using elpa-devel, though, the user might opt into having "the latest" mean "the latest commit in master"). >> BTW, if you recall the threads before Eglot was added, I was against >> that, and one of the things I cited is an LSP client has inherently high >> development velocity. Maybe the LSP community will settle/mature/stop >> adding features one day, but it's not there yet. > > I don't see what development pace has to do with this issue. If a > package is being developed at a high pace, it might mean that the > stable version will lag more. But what does this change in principle? It matters when we're talking not about simple additional, optional features, but about changes that keep pace with the evolution of the LSP standard, with new LSP servers that arrive, new changes in existing protocols. Things that users come to expect to be able to use now, and not in 3 years. Taking a conservative stance can work when the ecosystem supports it too. E.g. if every LSP server that we support now had an implicit promise to be properly maintained for 3 years since, at least. I don't think that's the case. Almost every one could be deprecated in that time frame, with community being recommended to switch to a newer one. >>>> Because since we've decided in favor of stability of package.el, and >>>> against eglot's easy upgradability, I would suggest to backport Eglot >>>> 1.14 to emacs-29. >>> >>> I won't object. In fact, I asked up front why not. >> >> Note that that suggestion comes with a fix to eldoc which you so far >> have rejected for emacs-29. > > You mean, the change in ElDoc that avoids the "jumping mode line" > issue? If so, it is unfortunate for Eglot to depend on that, because > it means users of Emacs 29 will be unable to upgrade to Eglot 1.15 > without by side effect installing a newer and potentially less stable > ElDoc. (I also am surprised that change is a must for Eglot 1.15.) Sorry if that was unclear: yes, the fix for "jumping mode-line and blinking text", but not as a bump in dependency. Just to backport the fix to eldoc.el inside emacs-29. But Joao has explained that that idea is impractical because Eglot 1.14 depends on Eldoc 1.14.0. And I just wanted a particular fix from it. So backporting the thing I wanted from Eglot 1.14 (taking up much less space in the echo area) is not really feasible because it depends on a fairly recent addition to eldoc. To clarify: I made that suggestion from the premise that we do expect and encourage a fair fraction of the users to use just the versions of Eglot and Eldoc that come with Emacs 29, and never upgrade to the latest ones. > So this again goes back to the main issue: how should the stability > considerations affect development of core packages and their > "stability gradation"? Developers of core packages should keep these > aspects in mind at all times, and, for example, avoid dependencies on > other packages that aren't absolutely necessary. I agree with that stance, in general. And as per above explanation, Eglot 0.14 depends on Eldoc 0.14.0 not because it's the very latest and spiffiest version, but because it needs a particular feature from it.