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: Sat, 09 May 2020 15:43:14 +0300 Message-ID: <83ftc9ffdp.fsf@gnu.org> References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> <835zd5h6tq.fsf@gnu.org> <83mu6hfjgx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="57270"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, rms@gnu.org, emacs-devel@gnu.org To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 14:44:09 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 1jXOpo-000Ejs-Sp for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 14:44:04 +0200 Original-Received: from localhost ([::1]:55494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXOpn-0004bx-F7 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 08:44:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXOpI-0003aY-52 for emacs-devel@gnu.org; Sat, 09 May 2020 08:43:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51511) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXOpH-0007H0-QW; Sat, 09 May 2020 08:43:31 -0400 Original-Received: from [176.228.60.248] (port=3844 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXOpA-0007wh-O5; Sat, 09 May 2020 08:43:25 -0400 In-Reply-To: (message from Philippe Vaucher on Sat, 9 May 2020 14:13:29 +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:249414 Archived-At: > From: Philippe Vaucher > Date: Sat, 9 May 2020 14:13:29 +0200 > Cc: Richard Stallman , Joost Kremers , > Emacs developers > > > > Can you give it another try? And if you still don't understand I'll > > > explain it another way. > > > > Please believe me when I say that my interpretation of what you wrote > > is such and such. > > I believe you it is, I was asking you to *try* to find another > interpretation. Since you don't want to do that Can we please assume that each one of us reads the other's messages attentively, and tries to understand and interpret it in good faith? > "For most users of dash.el and s.el, they will be surprised to see > dash.el accepted in ELPA but not s.el because they might feel these > packages are very similar in nature (provide high-order programming > discoverable functions to Emacs). To them it might look inconsistant > and they might wrongly assume emacs-devel is driven by arbitrary > decisions when it comes to accepting what goes into ELPA. Without a > good communication on why s.el is refused but dash.el is not, many > people could deduce that ELPA is a dead end and that only MELPA is the > sane route, further distancing ELPA from "where the real development > of emacs packages happens"". How is consistency relevant here? They are 2 different packages targeting different domains. Each one of them should be assessed separately and on its own merit. Thus, I see no reason for people to be surprised that two different packages are handled differently. (And the discussion is not yet over, so what will be the conclusion is so far anyone's guess.)