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.devel Subject: Re: Stability of core packages Date: Sun, 30 Apr 2023 09:21:06 +0300 Message-ID: <83ilddq4a5.fsf@gnu.org> References: <87a5zj2vfo.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> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <871qkfirbl.fsf@web.de> <83ildr6qhu.fsf@gnu.org> <83bkj7qk4m.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="30622"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mohsen BANAN Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 30 08:21:28 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 1pt0R6-0007if-2O for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Apr 2023 08:21:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pt0QH-0003Qo-O7; Sun, 30 Apr 2023 02:20:37 -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 1pt0QC-0003QP-Qx for emacs-devel@gnu.org; Sun, 30 Apr 2023 02:20:33 -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 1pt0Q8-0000if-RR; Sun, 30 Apr 2023 02:20:28 -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=D1/HyUx6vtIXSD4IxIulmaLiF4840+0xxotJTJNMD2U=; b=M4yAsvxa/QfjnnFFk1m7 Pf7joGvThReLUQCc/xpVZZaWAo9A4TKFiZIAZQ0uWlVgRzN9Hj7PbFH7NFr0LUOnK6cpVVyBJoFPN Ymi0UGPX0oCw9+yN/be6XCPad1EAgy6CtBaWoATZ1S1GM55pKFinO1J6TXApz0XfFlVB+/UkSpDzr hcuJOBFaSHGJe7zuQxbHJfztjS9pw26s6n0ebKo7etlNBw4Dmj4w51rDALI6/b5RGJmjCXa0CDx5t wn6cjv0UaCk9amx+vEG+l2P2iW9Nu7Jqqg94FTF5Kb6lsgadrB1Dj5vx+X1GF9t2hMOCNYfFqxrvf ciEzZx7Oc/fsTA==; 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 1pt0Q7-0004Hk-Vg; Sun, 30 Apr 2023 02:20:28 -0400 In-Reply-To: (message from Mohsen BANAN on Sat, 29 Apr 2023 14:47:51 -0700) 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:305726 Archived-At: > From: Mohsen BANAN > Cc: emacs-devel@gnu.org, João Távora > > Date: Sat, 29 Apr 2023 14:47:51 -0700 > > > > > I've read this several times, and I admit I still don't really > > understand the suggestion. Maybe it's because you are using some > > terminology without explaining it in enough details, perhaps because > > you assume prior knowledge of what it means. > > Sorry about that. > > In fact, that is the case. I was assuming that you > and others would be familiar with the lessons > learned from the "straight.el" and doom emacs > efforts over the past many years. My apologies. > [...] Thanks. I think I understand now what you are proposing. However, this is not what the current discussion thread was about. You are describing the technical means of tracking the collections of versions/snapshots/commits of packages that are known to work well with a given release of Emacs. By contrast, the issue I raised, which I think is a prerequisite for selecting any such technical means, was: what are the levels of "package stability" we want to support, and what are the criteria for each supported level? Once we have that figured out and agreed-upon, we can proceed to discussing how to support those stability levels from the technical POV. > Eli, if you have not used straight.el, I suggest > experimenting with it. Sorry, I cannot afford that: not enough time left, after all my other duties here are done. But I don't think I need to do that in order to understand what you are proposing. For that matter, I don't really see a significant difference between explicit versioning of package releases and using commits/tags for the same purpose. After all, a version is just a tag in the repository, i.e. a label of a commit. So they are all equivalent. And since in practice the only source of stability data of a package is the maintainer(s) of that package, the reason for using commits instead of release version tags seems weak to me; moreover, it assumes some significant team of people unrelated to any package that keeps track of stability and dependencies of a large number of packages, something that IMO is impractical for Emacs. But as I said: these are secondary issues, from my POV. We are not yet at a point where these issues are of any practical importance for our package system. And one more thing to keep in mind: these issues are from my POV most important for the so-called "core" packages, which are those that need to be shipped as part of the Emacs release tarball, but are developed and maintained outside of emacs.git. None of the package systems you mention have ever faced and handled this situation (with the possible exception of XEmacs, years ago, but we all know where that went...).