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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: Philippe Vaucher <address@hidden>,
>   address@hidden,  address@hidden,  address@hidden
> 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.