Re: ELPA policy

[Stephen Leake]

John Wiegley <address@hidden> writes:

>>>>>> Eli Zaretskii <address@hidden> 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.

ELPA packages that other core code depends on (like CEDET; xref uses it
- called "core ELPA packages" hereinafter) have to be in every
developer's build environment everyday; the other core code has to see
the current version of the package, and it has to be the same for every
developer.

If core ELPA packages are in the ELPA git repository, you would copy
some subtrees of the ELPA git workspace into the Emacs git workspace.
People have looked into doing this, but it gets messy and confusing.
"git fetch" is dealing with two upstreams for one workspace. There has
been talk about git submodules, etc, but nothing concrete.

The alternative, which is being implemented by the :core external
package feature in Gnu ELPA, and has been shown to work (but has some
details to work out), is to keep core ELPA packages in the emacs
git repository. Then they are part of the developer's build environment
using the current git workflow, and they are included in both the emacs
tarball and the ELPA package server with the current release workflows.


There are two rationales for moving a package to ELPA:

1) Allow a release schedule independent of the core Emacs release
   schedule.

2) Reduce the size of the Emacs git workspace, which simplifies managing
   it.

But a _core_ ELPA package must remain in the Emacs git workspace, so the
only rationale for moving a core package to ELPA is for an independent
release schedule.

> There are three actions I'd like to take from here:
>
>   a. That we clearly document an ELPA policy we all agree on;

In admin/notes/elpa ?

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

It's not clear that "really big" implies "independent release schedule".
"externally managed" implies that.

"not used by other core code" is also a good reason to move a package to
ELPA. 

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

If we use the approach of keeping core ELPA packages in the Emacs git
repository, there is _zero_ friction for the current core Emacs
developers; the only change is in the ELPA config scripts. 

-- 
-- Stephe