Re: ELPA policy

[David Engster]

> And why do I have to submit bug reports against an ELPA package for
> violation of our coding conventions?  I'd expect the maintainer of the
> package to be asked to fix those as a precondition for accepting the
> package in GNU ELPA, or at least as a long-term plan to which the
> maintainer agreed in advance (in which case no bug report would have
> been necessary).
>
> What am I missing here?

The README for GNU ELPA states:

We do not impose a particular coding style on GNU ELPA packages, but of
course we recommend the coding style used in Emacs's own source code.
Furthermore we recommend the following:
- Use `cl-lib` rather than `cl` if it all possible.
- Use lexical-binding if it all possible.
- Try and fix the warnings emitted when compiling the package with a
  recent Emacs.

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).

-David