Re: ELPA policy

[Aaron Ecay <aaronecay@gmail.com>]

Hi John,

Thanks for setting this out very concretely.

2015ko azaroak 9an, John Wiegley-ek idatzi zuen:
> 
>>>>>> 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.

The one thing that I see missing from this list is a way to take
packages that are developed in emacs.git and distribute them on an
ELPA.  (Either GNU ELPA, or a (g)new ELPA as was suggested by Eli.)
This would be the inverse of your 3: packages that feel like core
packages to emacs devs, but feel like external packages to users (at
least in the sense of receiving updates outside of the emacs release
cycle).

I’m not sure if that omission was intentional or not.  I hope it wasn’t:
this model of distribution has been chosen for several important
“low-level” packages, like seq, cl-lib, and let-alist.

If this addition is desired then:

[...]

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

This list needs an additional item, namely the development of the
script that publishes elisp from emacs.git to an ELPA.  I think people
have said that Fabian is already working on this.

Thanks,

-- 
Aaron Ecay