From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Sat, 09 May 2020 10:16:38 +0200 Message-ID: <871rnt7cbd.fsf@randomsample> References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <83zhaij4qn.fsf@gnu.org> <835zd6ihns.fsf@gnu.org> <83h7wphblf.fsf@gnu.org> <875zd57e7e.fsf@randomsample> <837dxlh77o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127279"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 10:17:40 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 1jXKfz-000WxJ-4x for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 10:17:39 +0200 Original-Received: from localhost ([::1]:48810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXKfx-0002NR-Nh for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 04:17:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXKfA-0001UP-Ps for emacs-devel@gnu.org; Sat, 09 May 2020 04:16:53 -0400 Original-Received: from zplane.randomsample.de ([2a03:4000:42:1a1:9400:eeff:feb4:c8a0]:56840) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXKf5-0004ou-Le; Sat, 09 May 2020 04:16:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q5BmFNlhGuoDTExV+onK+iOpHV+5y0RwmolQ1AgL91E=; b=K+ZMsViPtZt72ArqV4cdEqrMH ZmdgRLB+h1lZi1/5696rnEDwnCvAmzEQ35bGoNfWOu8RCn1DTEFtmDZABq9mUyNrNT3W2H1M3U4oI XlpTXLRDEP8vqrJWuyI/Jq9HWvYPnVpVAhdCZR+4GpuH4Z8uWQbIMvq6Kjn/lpIM+Bv1BNA+TcEIB xLVq2iEUhfPk5QoeyHrBVp13120zALlYQ3sCBlxYuhN/uA/XzEYXfgqZohbwoSJz7SSpI4882Ljl+ 7rdoBqDQQc3tk7DSAm37CT9bJpYbYd7CJ3wiEGbRzuxdwvu6xBt2kxHIwEoC6JLy0o/90wXY+OUKw ETY2pq/GQ==; Original-Received: from [95.90.186.238] (helo=void) by zplane.randomsample.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jXKf1-0001CH-84; Sat, 09 May 2020 10:16:39 +0200 In-Reply-To: <837dxlh77o.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 May 2020 10:56:43 +0300") Received-SPF: pass client-ip=2a03:4000:42:1a1:9400:eeff:feb4:c8a0; envelope-from=deng@randomsample.de; helo=zplane.randomsample.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/09 03:35:57 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:249373 Archived-At: >> From: David Engster >> Cc: Stefan Monnier , emacs-devel@gnu.org >> Date: Sat, 09 May 2020 09:35:49 +0200 > >> >> From: http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README >> >> So from my understanding: Following Emacs coding guidelines is a >> recommendation, but not a precondition for getting packages into >> GNU ELPA. >> >> If we start bundling certain ELPA packages with Emacs proper, then of >> course these special "core packages" would need to adhere to the Emacs >> coding style. I don't see any difficulty in making this distinction >> between core packages and the rest. And I also don't see any problem to >> put s.el in ELPA and say: note that using this package is against the >> Emacs coding style, so as long as you depend on this packages, it cannot >> become a "core package" in the future (same for dash.el). > > If we mark some ELPA packages up front as unsuitable for inclusion in > core, then I guess this could be acceptable. It does mean that such a > decision would make it hard to change our minds later, though. But at > least we should have an indication in each package whether it is or > isn't exempt from our conventions, something we don't have now. If you look here http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/externals-list you'll see that there are already packages marked as ":core" which all currently refer to a path in Emacs proper. This way, they could be overriden through GNU ELPA, and they of course need to adhere to the Emacs coding style. You are right that it will be difficult if we decide a package should become "core" and currently does not adhere to the Emacs coding style, but frankly, we should be more worried that this ship has already sailed far away. Many packages which are absolutely essential for a modern programmer's editor are already only available through MELPA. If we want to make GNU ELPA more relevant, we need to lower the hurdle for inclusion. I also fully agree with Stefan that we should make it possible for packages that have non-FSF copyright to be included. Of course these packages could never become "core", but having them installable throught GNU ELPA would be the next best thing. > Moreover, our conventions not being an absolute requirement, I think > _some_ requirements should still be non-negotiable, because we cannot > just accept anything. Otherwise any request for a change could be met > with an argument like "but I'm not under any obligation to comply" or > somesuch. I don't see any such requirements described in README, so > my question still stands, I think. Yes. For instance, it is clear that a package in GNU ELPA must not recommend or even depend on non-free software. -David