Re: ELPA policy

[John Wiegley <jwiegley@gmail.com>]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> It was made before -- that's the "let's move Org and Gnus out" variant, to
> which I said I could easily agree. And then there was the "move everything"
> one, to which I object for the reasons stated. What I meant was that there
> was no 3rd variant, AFAIR.

Wow, a lot of discussion about ELPA policy, this is great. We definitely have
an opportunity here to bring clarity to an area that is on people's minds.

I agree with a lot of what I read, although it was a too spread out for me to
add specific quotes here. Let me just summarize a possible path forward:

 1. Things that are maintained by the core Emacs developers should be in core,
    and in the Emacs.git repository. This makes it easy for them to access and
    build, search history, read emacs-diffs, etc.

 2. Things that are maintained outside of Emacs, but contributed back for
    inclusion, should be in ELPA, and in the Elpa.git repository. This
    includes Gnus, Org, CEDET, and a few more. (We don't want to go crazy,
    so let's start with the big ones).

 3. There should be a defined subset of packages that get copied from ELPA
    into the Emacs tarball during release, and an easy way to manage this list
    for the core developers. That way, certain packages like seq.el and
    stream.el can feel like "core" packages to users, when they are really
    "external" packages from the point of view of the core developers.

 4. Everything else in ELPA is Internet-installation based, as it is today.

I would very much like for ELPA to be a way to:

  - give the core developers a smaller surface area to focus on;

  - allow ELPA package maintainers to "have their package in Emacs", while
    retaining nimble in their own development process and in delivering
    updates to users;

  - allow the core maintainers to decide what exactly is going into "Emacs":
    For example, I wouldn't want to pull Org releases into the distribution
    from a submodule; I really do want a version of that source code to be in
    ELPA, so we can separately patch if there are last minute problems.

ELPA should thus benefit core developers by reducing load, and benefit package
maintainers by being an easier platform for their contributions and their
users. If it causes extra work for anyone, that's something I'd want to
change.

There are three actions I'd like to take from here:

  a. That we clearly document an ELPA policy we all agree on;

  b. That we move "external" packages from core into ELPA, starting with the
     really big ones;

  c. That we assess any points of friction after doing so, and adjust as
     necessary.

John