>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

SM> But that's exactly what I don't want: GNU ELPA should not be just a
SM> distribution of third party packages. For that, we already have MELPA
SM> which works just fine.

I agree also. When we make a release of Emacs, there should be at least enough
vetting of what's in ELPA that people can install those versions with some
degree of confidence. Otherwise, there'd be no reason for us to do anything
more than accumulate sources in a separate repository.

The idea behind "core" and "tarball" ELPA is that we're investing even more in
ELPA than we are now -- for a limited set of packages -- to the extent that
we're willing to add them to the tarball, or allow our core packages to depend
on their functionality.

There's also the possibility that we could add another category, maybe called
"community ELPA", that would just be a link to some external repository. In
that case, the only assurance we'd be providing is that we've reviewed their
copyright status, and have confidence they can be considered part of the GNU
Emacs project. But this would need periodic updating to be assured of
compliance, and I'm not sure we have that manpower.

Either way, our management of ELPA needs to be stepped up, with varying
degrees of oversight. The real question right now is how we achieve this
technically, and Git is the first of those puzzles we have to solve, followed
by the build system.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2