Re: ELPA policy

[John Wiegley]

>>>>> Achim Gratz <address@hidden> writes:

> They could (and probably should) effectively be in the build environment as
> well. In other words, I would try to not pull them into the release tarball
> at the last possible moment. One thing that would make difficult is to test
> interactions between such "external core" packages and here I have to agree
> with Eli that this has potential for degradation of quality.

Could this be solved by branching ELPA leading up to a release -- this being
the "frozen ELPA" that we do integration against before cutting the tarball --
while cherry-picking fixes in from master? I think the way we proceed here
would be similar to what we do for Emacs itself.

> You'd do that with branches if it really becomes necessary. I don't really
> see why submodules could not be used, except for the extra rope they give
> you to hang yourself with. Any other solution is going to have the same
> basic complexity beneath and the potential to not work on some platform or
> other.

A submodule doesn't allow us to have "Org + some-patch-not-yet-in-Org".

> I maintain that ELPA should benefit Emacs users first.

I'm intrigued; could you clarify this a bit more? I saw what you wrote in
response to Eli, but that didn't really help. Specifically, do you have a
scenario in mind that is better for users and worse for developers?

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

> ...after the necessary changes to Emacs' build system and package.el are
> architected and implemented.

Agreed.

John