elpa.gnu.org repository sync with Emacs (was: rainbow-mode)

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 15 Nov 2010 22:15:33 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> I tried the elpa interface and it seems very nifty, but I do share the
GM> concerns expressed about what it all means in practice for the
GM> maintenance of the associated packages. As an "easy way to get a
GM> package that would otherwise not be in Emacs" (eg AUCTeX), it seems
GM> really nice; for farming out things that otherwise _would_ be in
GM> Emacs proper, not so much.

GM> Some of these issues would go away if these "non-infrastructure"
GM> packages (not AUCTeX etc, but rather the things that would have been
GM> added to Emacs before elpa) were hosted in a central Savannah bzr
GM> repository (or possible as a subdirectory in the existing Emacs
GM> repository that is excluded from the tarfiles; I'm not sure if the
GM> number of files in the Bzr version of Emacs matters very much), so
GM> that the Emacs developers can and do feel able to help maintain them.
GM> From my point of, the ideal thing would be something like a separate
GM> top-level "elpa/" directory in the normal repo, not compiled by
GM> default, that I could compile with `make elpa' or somesuch.

GM> Then putting something on elpa doesn't mean relegating it to being a
GM> second-class citizen.

On Tue, 16 Nov 2010 00:55:16 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> That's a problem with the current setup, indeed.  I think we should be
SM> moving towards a Bzr "packages" branch which we could checkout alongside
SM> Emacs and edit easily to fix bugs.

SM> There's a fair bit of work left to do to get to that point, tho.
SM> Part of the problem here is how to decouple edits from uploads, how to
SM> sync local changes with the upstream maintainer, etc...

I'll try to merge Glenn's comments, your comments, and mine into a plan:

1) add elpa/ directory to main Emacs repo (as a branch or subdirectory;
my vote is for a subdirectory that's not bundled or compiled because it
will get branched together with Emacs itself).  Make it available to a
dev checkout of Emacs as a file:/// URL (so it can be tested easily).

2) let the usual Emacs hackers access elpa/* normally

3) mirror elpa/ to a repo on elpa.gnu.org daily after reviewing the
changes (so it's a supervised pull, not automatic).  Allow admins to
trigger this from the web site.

4) Set up a deploy process of the elpa.gnu.org repo to the HTML tree
(with one package repository per major version as I suggested, plus a
"dev" package repository and an "all" package repository).  This can be
deployed automatically and manually.  Allow admins to trigger
deployments from the web site.

5) set up specific third-party packages to be fetched into the "all"
package repository daily on top of the deployment.  AUCTeX, BBDB,
etc. would be good candidates for this.

This lets us bundle Emacs-local changes to third-party packages into
clear diffs we can send back upstream.  It also separates "commit
something into the package repository" from "deploy the package
repository to the world."

Ted