From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: decision on moving core packages to ELPA; also move to obsolete? Date: Tue, 15 Dec 2020 17:01:42 -0500 Message-ID: References: <86a6ugnopl.fsf@stephe-leake.org> <83im94b17m.fsf@gnu.org> <834kknatxs.fsf@gnu.org> <83sg86apqb.fsf@gnu.org> <865z52oqfp.fsf@stephe-leake.org> <86wnxinbnx.fsf@stephe-leake.org> <83o8iuann7.fsf@gnu.org> <83h7omakyw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1805"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: daniele@grinta.net, stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 15 23:03:33 2020 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 1kpIPs-0000LF-2e for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Dec 2020 23:03:32 +0100 Original-Received: from localhost ([::1]:57706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpIPr-00015A-2y for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Dec 2020 17:03:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46014) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpIOJ-0008W3-K1 for emacs-devel@gnu.org; Tue, 15 Dec 2020 17:01:55 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63997) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpIOC-0005T9-3F; Tue, 15 Dec 2020 17:01:54 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BDA8110024D; Tue, 15 Dec 2020 17:01:45 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E109310021D; Tue, 15 Dec 2020 17:01:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1608069703; bh=lDJOsQ8qDBEp3SsaQlTBZQseFqyVFE4NtCbH3uFnA0E=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=KZJtCC+jX1i75fvMHoV7zL9xeOxLQTM1BRqSuN9y6FJIBKG8ZCAc7w03/9qOp6d39 xXKF+LDK+u09aqJGDYSCMQFPUH1MwhD2a2fApScafwlTHAEbxm0XT5o89qKkmtDvIu kHnHGGklyW6q7O9fxu4Xgr0T3jk0+4rWZIvm+EhLy2aRSR2cOy2gLBrGiNlCYLZAix Akaai1LhpZ9mlDus1hqpKVWvGxzCZ5nBU92ymFHyN/Jmrqr6JFGSlXgyZyWo6Ix0n9 eSpH8dwFYVoKxOscMFIeNdNdlMDlVS1PJwCP1mVlJsdpsnjscIB3ptgiYmWbPcPJBz pGrvJmxwqJ7xg== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 98F1B120278; Tue, 15 Dec 2020 17:01:43 -0500 (EST) In-Reply-To: <83h7omakyw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Dec 2020 22:11:03 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:260935 Archived-At: >> I'd expect it to work the same as for Org, MH-E, Gnus, you name it. > > What do you mean by "the same as"? Currently, it is not our decision > which Org/MH-E/etc. version will be in what Emacs branch. The > respective developers make that decision and simply push the version > they decided into our repository. > > Once we separate the repositories, the decision will have to be made > by whoever prepares the tarball, and I don't see how he or she could > be equipped to make that decision, nor how the packages are organized > for this modus operandi. You tell me how you want it to work, and we'll write the support code accordingly. E.g. one way this could work is as follows: Currently every GNU ELPA package has a corresponding branch `externals/[PKGNAME]` in `elpa.git` where the source code is kept. We could add to elpa.git a bunch of branches `emacs/[PKGNAME]` which keep the version of the code we want to include in the next release of Emacs. Those branches can be updated whenever we or the package's maintainer deems appropriate. Our tarball-builder-script would then grab the bundled packages's code from those branches. > I'm not sure most of it is done. Over the years, we had several long > discussions here about this stuff, and AFAIR none of them ended with > solutions. All those issues raised in those discussions are still > with us, waiting to bite us. Most of the harder discussions have to do with the unsolvable problems: E.g. we'll have code in the tarball that's not present in a Git checkout, which means that people who work from the Git may be disappointed. We could "fix" that by making our Git script fetch the extra code as well, but what about those that don't want it (or what about the extra complexity of having to pull/update those branches)? Also, the proposed bundling doesn't let Emacs's own code depend on GNU ELPA code, so it still wouldn't allow us to use `dash.el` inside Emacs. I don't see any need to "solve" or discuss those issues before we can bundle packages. > We need to go over those issues and solve them before we can seriously > talk about unbundling ada-mode or any other package. I'm not talking about unbundling anything here. I'm talking about bundling *additional* packages currently not distributed with Emacs. [ BTW, ada-mode is already "unbundled", AFAIK. ] Obviously, the ability to bundle GNU ELPA packages might allow/encourage moving some packages from Emacs to GNU ELPA. It's indeed one of the longer term benefits that makes bundling interesting, but in the short term (i.e. Emacs-28), this is not on the table AFAIK. Stefan