Re: ELPA policy

[Stephen Leake]

John Wiegley <address@hidden> writes:

>>>>>> David Engster <address@hidden> writes:
>
>> the main question is whether something provides infrastructure for other
>> packages to use.
>
> Sounds like a good sentence for an ELPA policy. :)
>
>> It is still not clear to me what exactly is gained by moving core packages
>> to ELPA.

Since no other core code depends on ELPA, CEDET is _not_ a "core package".

Rather, CEDET is a "tarball package"; it is in Emacs git solely to
ensure that it is included in the Emacs release tarball.

A better example of a possible "core ELPA package" is the "seq" package.

> Agility. 

I hear that as "easier to make small/frequent changes". That is what the
ELPA release policy gives you, yes. So this is one rationale for moving
packages to ELPA.

> What is appropriate. 

That's what we are trying to figure out :)

> Knowing when a thing goes into core, and when in ELPA.

Ditto.

> Org is an application, it's not infrastructure; the same with Gnus. *Parts* of
> Gnus might rightly be considered infrastructure, but the whole of Gnus just
> doesn't belong there. Parts of CEDET probably do belong in Emacs core, but as
> an application, I don't think the whole of it does.

I think the distinction between "tarball package" and "core package" is
helpful here.

I'm guessing that the main motivation for including Org and Gnus in
Emacs git (well, CVS back then?) was to include them in the release
tarball. If we have a mechanism to allow that for ELPA packages, moving
them to ELPA makes sense.

-- 
-- Stephe