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

[Dmitry Gutov]

On 17.05.2020 17:24, Eli Zaretskii wrote:

> I'm saying that maybe we shouldn't agree so easily to put a package on ELPA if 
> the author would like more than just distribution services.

I'd say it all depends. We probably aren't going to simply follow what 
the author will be asking for, either.

Do they want code review? We could do it once (couldn't we?), but if the 
author wants all the changes reviewed all the time, we would probably do 
that only for most important packages. Ones that will be enabled for 
default, maybe?

On the other hand, I don't see why we couldn't do code reviews on ELPA 
for select packages, if the authors ask for it. I don't see that 
happening a lot anyway.

Do they simply ask to be included? Perhaps we should ask why. Up until 
now, we often pointed at GNU ELPA and proposed that the package will 
live there. It seems to have worked out fine in those cases. Even aside 
organizational issues (different upstreams, etc), simply including a 
package in Emacs will hardly help it gain users (people don't often 
examine the contents of our distribution). Whereas being featured in 
'M-x list-packages' with a good summary *can* make it well-known.

Do they want to be included and turned on by default? This seems like a 
good reason, if we really like it.

On the flip side, not every discussion that starts with 'I propose to 
put pkg-X in GNU ELPA' should end there.

As I wrote in another thread, maple-minibuffer is something we should 
consider sooner or later for the default behavior, for friendlier 
positioning of the minibuffer on graphical displays.

Another example is elegant-emacs, suggested in yet another thread by 
Nicolas P. Rougier. There's nothing stopping us from featuring it in GNU 
ELPA (right?), but we would get the most value if we really examine it 
and look for pieces to put into the vanilla Emacs by default.