Re: ELPA policy

[Stephen Leake]

David Engster <address@hidden> writes:

> John Wiegley writes:
>>>>>>> David Engster <address@hidden> writes:
>>
>>> This is not about reaching a consensus. This is about you giving proper
>>> reasons for such a big change.
>>
>> To be clear, I would also put Eshell (though not pcomplete) into the category
>> of "big things that should be in ELPA" -- albeit, the subset of ELPA that 
>> will
>> be in the release tarball.
>>
>> It's hard to pin down why in a manner that fits in an e-mail. If Eshell were
>> in ELPA today, and we were talking about moving it into core, I would have
>> just as much trouble justifying that move too. Perhaps this simply 
>> underscores
>> the fact that we don't have an agreed upon ELPA policy we can all refer to.
>
> In my opinion, the main question is whether something provides
> infrastructure for other packages to use. 

I think it is a reasonable goal to allow ELPA packages to serve in that
role, as long as the "other packages" are also normal or tarball ELPA
packages.

> This is precisely what CEDET tries to do.

Yes.

However, now the shoe is on the other foot: why must infrastructure
packages be in Emacs core?

I think the trigger is "some other _core_ code wants to depend on it".
That would trigger a move to Emacs git, as a core ELPA package (the
package could still have intermediate released via the Gnu ELPA server).

> I wouldn't have much trouble with putting parts of CEDET in ELPA,
> namely those parts that do not directly provide infrastructure, like
> support for certain languages, project types, indexing tools, etc.

Good, but let's not try to do that for Emacs 25; since we are trying to
get to feature freeze, it's too much.

> It is still not clear to me what exactly is gained by moving core
> packages to ELPA. 

One gain is making it clear that other core code is not allowed to depend
on it. This is in turn to ensure that it doesn't creep into the dumped
code. But I'm not sure that's an important reason.

-- 
-- Stephe