[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

From: Eli Zaretskii
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Sat, 09 May 2020 15:43:14 +0300

> From: Philippe Vaucher <address@hidden>
> Date: Sat, 9 May 2020 14:13:29 +0200
> Cc: Richard Stallman <address@hidden>, Joost Kremers <address@hidden>, 
>       Emacs developers <address@hidden>
> > > 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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]