Re: ELPA policy

[David Engster <deng@randomsample.de>]

>> From: David Engster <deng@randomsample.de>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> Date: Sat, 09 May 2020 09:35:49 +0200
>
>> 
>> From: http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README
>> 
>> So from my understanding: Following Emacs coding guidelines is a
>> recommendation, but not a precondition for getting packages into
>> GNU ELPA.
>> 
>> If we start bundling certain ELPA packages with Emacs proper, then of
>> course these special "core packages" would need to adhere to the Emacs
>> coding style. I don't see any difficulty in making this distinction
>> between core packages and the rest. And I also don't see any problem to
>> put s.el in ELPA and say: note that using this package is against the
>> Emacs coding style, so as long as you depend on this packages, it cannot
>> become a "core package" in the future (same for dash.el).
>
> If we mark some ELPA packages up front as unsuitable for inclusion in
> core, then I guess this could be acceptable.  It does mean that such a
> decision would make it hard to change our minds later, though.  But at
> least we should have an indication in each package whether it is or
> isn't exempt from our conventions, something we don't have now.

If you look here

http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/externals-list

you'll see that there are already packages marked as ":core" which all
currently refer to a path in Emacs proper. This way, they could be
overriden through GNU ELPA, and they of course need to adhere to the
Emacs coding style.

You are right that it will be difficult if we decide a package should
become "core" and currently does not adhere to the Emacs coding style,
but frankly, we should be more worried that this ship has already sailed
far away. Many packages which are absolutely essential for a modern
programmer's editor are already only available through MELPA. If we want
to make GNU ELPA more relevant, we need to lower the hurdle for
inclusion. I also fully agree with Stefan that we should make it
possible for packages that have non-FSF copyright to be included. Of
course these packages could never become "core", but having them
installable throught GNU ELPA would be the next best thing.

> Moreover, our conventions not being an absolute requirement, I think
> _some_ requirements should still be non-negotiable, because we cannot
> just accept anything.  Otherwise any request for a change could be met
> with an argument like "but I'm not under any obligation to comply" or
> somesuch.  I don't see any such requirements described in README, so
> my question still stands, I think.

Yes. For instance, it is clear that a package in GNU ELPA must not
recommend or even depend on non-free software.

-David