Re: ELPA policy

[John Wiegley]

>>>>> Stephen Leake <address@hidden> writes:

>> Elpa.git should be a submodule referenced from within Emacs.git (under
>> "elpa").

> That's overkill; there are many packages in Gnu ELPA that core code should
> _not_ depend on.

I believe that no core code should depend on any ELPA packages. Such a
dependency would be a reason to move that package into core, no? If that's
really the case, no submodule reference is necessary after all.

> If this said "large packages that the rest of Emacs core does not depend on
> ...", I could agree.

Yes, I meant that.

> So this introduces a third kind of ELPA package: "distributed in Emacs
> tarball". A "tarball package" for short?

Yes, for ELPA packages, there would be two flavors: in the tarball, and not.
Some have suggested just putting everything in the tarball for now. So we
could defer this question until the size of the tarball mattered, or if a
particular package was so dynamic it didn't want a version frozen into the
tarball.

Note that going down this road starts to make the line between "core" and
"ELPA" very thin, with easy migration between the two when desired. For
developers it allows Git to focus better, but for users, the difference is
largely invisible.

> Except that Eric maintains that there is more to "CEDET" in Emacs core than
> just lisp/cedet/*. So to be clear, we are proposing to move only
> lisp/cedet/* to elpa git.

Yes.

> In summary, I'm proposing that there are three kinds of ELPA packages:

I think we have a lot of agreement here, but I'd still like a clearer policy
than just "if core depends on it".

John