From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Sat, 09 May 2020 10:56:43 +0300 Message-ID: <837dxlh77o.fsf@gnu.org> References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <83zhaij4qn.fsf@gnu.org> <835zd6ihns.fsf@gnu.org> <83h7wphblf.fsf@gnu.org> <875zd57e7e.fsf@randomsample> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="45004"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 09:57: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 1jXKMX-000BZh-BD for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 09:57:33 +0200 Original-Received: from localhost ([::1]:59100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXKMV-00077u-Q6 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 03:57:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXKLw-0006i1-5j for emacs-devel@gnu.org; Sat, 09 May 2020 03:56:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46859) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXKLv-00029g-3m; Sat, 09 May 2020 03:56:55 -0400 Original-Received: from [176.228.60.248] (port=1883 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXKLt-00052u-RD; Sat, 09 May 2020 03:56:54 -0400 In-Reply-To: <875zd57e7e.fsf@randomsample> (message from David Engster on Sat, 09 May 2020 09:35:49 +0200) 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:249369 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. 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.