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: Sat, 29 Apr 2023 09:26:33 +0300 Message-ID: <83bkj7qk4m.fsf@gnu.org> References: <87a5zj2vfo.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> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <871qkfirbl.fsf@web.de> <83ildr6qhu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22823"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: emacs@mohsen.1.banan.byname.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 29 08:26:52 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 1pse2m-0005jl-Ev for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Apr 2023 08:26:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pse1x-00065H-PR; Sat, 29 Apr 2023 02:26:01 -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 1pse1w-000654-91 for emacs-devel@gnu.org; Sat, 29 Apr 2023 02:26:00 -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 1pse1u-0006OU-Cn; Sat, 29 Apr 2023 02:25:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8pyMiKKdDFdeYYBtrVf8NebVOwMTQFYHayADrFRuEb0=; b=ld9HgptjQsds olu9iVsbDgSIHXMietRmF3g5pEM5En6m36psrcpftVwxCEgRROnINovRHH5k9Zk1R5VPe275jBBmo fn/k3tSRd7ECUkhjqG3G8SVr1/lUo3x5xiExpwHWNsj/YCLcwbQ0ZHil7/UD3Y0U1rJMBzMyBs7hi y3zlgRXP55PTKfu84p+QvGxwfh5tfpKqAF5ewhf5twyq1zniN1twq9nGSjeXy7XPfvZT9W+K4xH3y H+t1LE/QOoES1iTIW5R4aeNJrmomxl4NUh43vKTL6p1DuFnVFr8auSf3cA3Yq+8B97yHzLCMxJrFj 2IWlzLCFHB6ho9KwKS94hQ==; 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 1pse1s-0005ML-Bp; Sat, 29 Apr 2023 02:25:56 -0400 In-Reply-To: (emacs@mohsen.1.banan.byname.net) 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:305704 Archived-At: > From: emacs@mohsen.1.banan.byname.net > Cc: "Dr. Arne Babenhauserheide" , joaotavora@gmail.com, > jporterbugs@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org > Date: Fri, 28 Apr 2023 22:21:46 -0700 > > > I have been following this thread from a meta perspective. Thanks for chiming in. > Because we use git for everything and because it > is possible to take complete git snap shots of all > relevant packages, it is possible to easily > provide stability for the user based on snapshots. > > Consistent upgrades are then possible for new > consistent git snapshots. So, based on the snapshots > the packages are not stale and remain consistent > while evolving. > > This is what doomemacs does. For every package, > there is a git tag which doomemacs keeps with the > adoption of the package. The tags are guaranteed > to be consistent. With Blee (ByStar Libre Emacs > Environment) I do the same but instead of keeping > that tag with the packages, I keep central > manifests for emacs releases. So, emacs-28.1 has > its own packages manifest which can be upgraded > from time to time. All upgrades go to the > appropriate repo and get the appropriate tag based > on the manifest. I do this across all emacs > package archives -- which I see as collections of > git repositories. > > If you want to go with something like this, you > have to revisit the package retrieval model. > > For every release of emacs, you maintain a > separate manifest. And you keep updating that at > new releases and even in between releases. Since > all emacs archives are git based, it is possible > to apply this strategy to all of them -- where > each take care of its own consistency. 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. Here are some questions for which I didn't find answers, and which precluded me from following your suggestions: . what is a "git snapshot"? what does it include in the context of this discussion? . what is meant by "upgrades for new consistent git snapshots"? how is such an upgrade done, and how does it work in practice? . what are those git tags which doomemacs keeps with the packages? what does each such tag indicate, and how are these tags maintained and updated? . what does it mean for a git tag to be "consistent"? . what are those "central manifests" you describe for Blee? what does each manifest contain and how is it used? . wrt your proposal of keeping separate manifests for each Emacs release, how will a manifest for a specific release be updated, and where will it be kept and made available for users?