Re: ELPA policy

[Ted Zlatanov]

On Mon, 15 Nov 2010 15:12:15 -0500 Chong Yidong <address@hidden> wrote: 

CY> Stefan Monnier <address@hidden> writes:
>> For new packages, I'd expect only a few people to have such rights,
>> but for updates, I'd expect something like "anybody with access to the
>> Bzr repository".  After all, if they can screw with the main Emacs
>> codebase, why not with the ELPA packages.

CY> One difference, though, is that screwing with the main Emacs codebase
CY> affects only those using the development version of Emacs, and we have
CY> mechanisms like the diffs mailing list for problems to be easily
CY> spotted.  After Emacs 24 is released, by screwing with elpa.gnu.org you
CY> can immediately affect users of deployed stable Emacs versions.

CY> So, we need to be a bit more paranoid for elpa.gnu.org than for our main
CY> repository.

This is one good reason to keep a separate repository per major Emacs
version, at least.  Then you can fix packages without so much fear.

CY> I agree, though, that it would be nice for Emacs developers to easily
CY> edit packages in elpa.gnu.org without going through an onerous package
CY> upload process.  I'm not sure how to set this up, though maybe the way
CY> the Org daily builds are handled can be used as a starting point.

I hope we make it easy to submit changes but harder to publish them.
See below for my staging suggestion.

CY> Maintaining a separate repository for every Emacs release sounds like a
CY> lot of work.  Currently, it's up to maintainers of upstream/external
CY> packages ensure backward compatibility with older Emacs versions,
CY> e.g. by introducing compatibility functions.  Obviously this system
CY> doesn't work perfectly, but it doesn't seem like we have the manpower
CY> for anything more elaborate.

Setting it up is really not hard, even if we don't use it.  Just add
"packages-MAJOR" and "packages-MAJOR.MINOR" to the default "packages"
repository on startup.  Those can be empty but when we need something in
them (and we will, I promise you), they'll Just Work.

The dev checkout version should also have "packages-dev" or some such
that's only enabled if you make a dev build.

All this is not hard if we use VCS branches.  It's a 1-to-1 mapping to
the Emacs repo's branches.  In fact the elpa.gnu.org repo could mirror a
subdirectory of the Emacs repo, which would solve the staging problem
(developers would just stage to the Emacs repo and the elpa.gnu.org
maintainers would publish from there).

I think the alternative approach, keeping it really simple now, will
require more manpower and drain more time long-term.

Ted