emacs-devel
[Top][All Lists]
Advanced

[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: Philippe Vaucher
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Sat, 9 May 2020 14:13:29 +0200

> > > 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.



reply via email to

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