Re: ELPA policy

[David Engster <deng@randomsample.de>]

>> From: David Engster <deng@randomsample.de>
>> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Sat, 09 May 2020 10:43:55 +0200
>
>> 
>> > If we are going to drop requirements, then what will distinguish ELPA
>> > from MELPA?  And what's the problem with having non-core packages
>> > available through MELPA, anyway? why do we need to have them in ELPA?
>> 
>> In principal, I agree with you. The problem is mainly Richard's stance
>> on this issue, which says that we must not recommend packages which are
>> not in Emacs or GNU ELPA, but that we should rather re-implement them. I
>> think that's a terrible waste.
>
> Is this only about "recommending" or not "recommending" a package?  Is
> this why we created GNU ELPA and invest non-trivial amount of effort
> in maintaining and developing it?  I very much hope there's more to
> it than just that.

We created GNU ELPA because we wanted a package system in Emacs. It was
simply the first, then things evolved to the state we have now, where
MELPA is the dominant package repository.

> I could understand if you'd say "use" instead of "recommend",
> i.e. have code in Emacs, which, if a package is installed, would use
> it.  That'd actually have the package's name in our sources, and would
> constitute some kind of "endorsement".  But as long as we don't use
> any of those packages, why should we care what other people like or
> don't like?

Sorry, but you lost me there. All I'm saying is that there's a whole lot
of terrific packages out there but which we must not recommend to users,
although they are free software and often vastly superior to the things
that are built into Emacs. For instance, there's a discussion going on
about making a video showing Emacs' capabilities, but I assume we'd not
be allowed to show Magit. That's a huge loss.

-David