Re: ELPA policy

[Eli Zaretskii]

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

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.