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: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Mon, 11 May 2020 19:24:48 +0300 Message-ID: <83blmubfsf.fsf@gnu.org> References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> <835zd5h6tq.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="42253"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 11 18:25:44 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 1jYBFQ-000Ars-AY for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 18:25:44 +0200 Original-Received: from localhost ([::1]:36040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYBFP-0003zr-Ah for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 12:25:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYBEj-0003AN-Nc for emacs-devel@gnu.org; Mon, 11 May 2020 12:25:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40330) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYBEj-0005Qk-CJ; Mon, 11 May 2020 12:25:01 -0400 Original-Received: from [176.228.60.248] (port=1417 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jYBEa-0001eb-G9; Mon, 11 May 2020 12:24:53 -0400 In-Reply-To: (message from Stefan Monnier on Sat, 09 May 2020 10:11:00 -0400) 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:249815 Archived-At: > From: Stefan Monnier > Cc: Philippe Vaucher , > joostkremers@fastmail.fm, rms@gnu.org, emacs-devel@gnu.org > Date: Sat, 09 May 2020 10:11:00 -0400 > > > I as a Emacs user would think s.el is a bad addition to ELPA -- it > > doesn't add anything special, > > It is used by hundreds of packages. So as long as it's not in GNU ELPA, > none of those hundreds of packages can be even considered for inclusion > into GNU ELPA. > > That's the special that it adds. So we are going to add s.el because it is used by hundreds of packages. And then we will add some of those hundreds, and then we will add some more packages that use those other packages. And so on and so forth. But to what end, may I ask? Those packages already exist and are available from MELPA, people are already using them, and installing a package from MELPA is no more effort than from ELPA. So what is the purpose of adding them to ELPA as well, if all we are going to do is mimic the same procedures and requirements as MELPA? GNU ELPA is (or was?) supposed to be an extension of Emacs. Being an extension means the packages need to undergo almost the same quality control as the code in core. Deferring such quality control to some imaginary future means simply that we decide not to do that: how can we seriously expect that the package authors will agree to changes to which they don't agree today, especially after so much time has passed and so many other ELPA packages already depend on them? Those requirements are not arbitrary, they are supposed to keep Emacs easier to use, develop, and maintain. By waiving those requirements today we in fact waive our ability to decide later whether or not to include a package in Emacs. By that we actually remove the main, if not the only, reason to have ELPA at all. > > IOW, are you saying that the technical details of the package's > > implementation should not matter, for fear of sending the wrong > > message? > > Pretty much, yes. Not just "for fear", but because we do want to > encourage people to share their code (which can always be improved if > necessary). They already share their code, on MELPA, on GitHub, on GitLab, etc. Why do we need to invest our efforts into one more repository "like that"? It makes no sense at all.