New ELPA policy proposal (was: ELPA policy)

[Oleh Krehel <ohwoeowho@gmail.com>]

Hi all,

In the previous thread, a few concerns were posted:

1. Having ELPA separate from Emacs requires internet access to install
extra packages, which might be undesirable.

2. Merging all ELPA commits into Emacs might be too noisy.

3. Waiting for new core features until Emacs release, as opposed to
obtaining them immediately from ELPA.

Here's my proposal to address these issues:

1. Only packages which are relatively independent are allowed to be
moved to ELPA. This is a rule that we adhere to right now, I just wanted
to re-state it. And it's important for the next point.

2. Each package is developed it its own Git repository, and is included
into the common ELPA directory as a Git submodule.  No actual code is
ever committed into the Emacs git repository, only the commit hashes,
when an ELPA package maintainer deems it appropriate to merge, e.g. the
package is assumed to work fine with the current Emacs git version, at
the moment of the merge. Then there will also be some script, like

    $ make elpa

that will update all packages with "git submodule update".  In my
opinion, this is very close the model of MELPA - a very successful Emacs
package archive with 2786 packages to GELPA's 130. The only difference
here is that the updates aren't automatic, and are instead up to the
maintainer, which should give more stability.

3. On Emacs release, we'll have emacs.tar (for people with low
bandwidth) and emacs-with-elpa.tar (the recommended download). The user
will have several options to configure the Emacs installation:

    a. Only core Emacs.

    b. Core Emacs with a separate offline ELPA repository. The user will
    be able to install from this offline ELPA repository at any time.
    This should be a nice default option, I think.

    c. Emacs with all ELPA packages installed, because why not?

4. Thanks to the version system, it will be possible to update these
"offline" ELPA packages with the current online version, just like it's
currently possible to have the GELPA version of a package to update to
the MELPA version. Additionally, with the feature of pinning a package
to an archive, we give the user the flexibility to pin ELPA packages to
the offline ELPA repository, instead of having them update automatically
from GNU ELPA.

regards,
Oleh