From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 9 May 2020 14:13:29 +0200 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> <835zd5h6tq.fsf@gnu.org> <83mu6hfjgx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="67187"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Joost Kremers , Richard Stallman , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 14:14:31 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 1jXONB-000HL0-WE for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 14:14:30 +0200 Original-Received: from localhost ([::1]:38860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXONA-0006ZW-Ir for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 08:14:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXOMh-0005p0-24 for emacs-devel@gnu.org; Sat, 09 May 2020 08:13:59 -0400 Original-Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:40876) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXOMg-0004GO-8n; Sat, 09 May 2020 08:13:58 -0400 Original-Received: by mail-lj1-x229.google.com with SMTP id y4so4467793ljn.7; Sat, 09 May 2020 05:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BdBT+1EasydmLQe2Yw5Y08wfAdrbRROFNkMXRLqxQII=; b=ZHR/+eS+4+IKlH0o3MUE4omlN7Wb63I0EeL1Re7F74cRdd10N6NRhkpdh0C08yja3R itf6al8o8bRQXBiZA4uBhl5r2xy+xL3okBsPln9OQKsF9Ry9q2twHE3/PPTDZ6u8c4wZ 5hesZjXSVdCQ9uZrHR1lBNiKTufRnCe1VujmI+cXnUY/UuhC2tCkFwLbutmPGhwyqJVT L0dhvpvFaj+tULYf/IOgdJs85vNco0+uGb1kz5LlJ5665xot/BuX3u1csvTv+KrKSI6d oUB61uRKhLhgm4fHliGj7MdlR7SzjxhO2+HsoiXUMpzOXmC+Cs4gnE36m6BSO1GoEyuZ Z0lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BdBT+1EasydmLQe2Yw5Y08wfAdrbRROFNkMXRLqxQII=; b=KhmRWfAwLtGFAbX8wALmay4MhdvxItOXPPaTMiZQfXDOgSnHsooyVU+Ohpa3NWR2X4 wHR7MnMdBjR0XCosv7bVx7HhvsiWEkTrm/TmDg76FCdKiP12bJkaFWuOEwxovA6owBfw ZrT6O1MPpOLvxdh0gqEFkWxgrbMfaWWgtloB1bN1GeWtlzIqEIirQ7CS5NisuIpzTwhe daxFzafo1s9sxBwRP1jlgpeLI5n+kFq6Vaxi+0ccnYUPfQuupVZ2ika0/WZV2tXCGRIl 9KvqPW+kfhS2SkISv4pIiugWcgg+nE5yysQ8ObQ0lRAwK+QnCFnIWmkxBNjdJUUyafXI 8ccQ== X-Gm-Message-State: AOAM533rZ/KO97yjs8tHOfss81ba4KRlW1l79I/XNYAEYAXsQ3DcVrjG MMr2mO5BSoG4lpVmkpccGA1t6SwiPOMGqtygTj0FMQEbni0= X-Google-Smtp-Source: ABdhPJznKxW3Ri/BezQYXpFEyKaHVl1TcNAndfDjtihR+5sJ/6j5Sx5l8JEm2K3AcvHorvT6cj/LsmK+TCUGrvMnFvQ= X-Received: by 2002:a05:651c:c8:: with SMTP id 8mr4375843ljr.182.1589026435447; Sat, 09 May 2020 05:13:55 -0700 (PDT) In-Reply-To: <83mu6hfjgx.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::229; envelope-from=philippe.vaucher@gmail.com; helo=mail-lj1-x229.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:249410 Archived-At: > > > Richard also proposed a compromise which AFAIU would allow it to be > > > added. For some reason, that proposal got no responses at all. > > > > I tried to find that compromise again, all I found was "See my message > > to Stefan for a change that would make s.el ok to add." but could not > > find this message. If you would be so kind as to quote Richard again > > so I have his perspective. > > Look here: > > https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00850.html Thanks! > > > > - For most users, dash.el and s.el are very similar in nature. dash.el > > > > is already in ELPA. If we refuse s.el, isn't it inconsistent? What > > > > about the message we send? > > > > Are you saying that popularity and similarity of a package is the only > > > criterion we should apply when deciding whether to add a package to > > > ELPA? IOW, are you saying that the technical details of the package's > > > implementation should not matter, for fear of sending the wrong > > >message? > > > 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, here is my re-formulation of what I said: "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"". There, hope it's more clear. Surprised you couldn't infer that from my first statement, but ok it's not the first time, I'll try to be extra explicit from now on.