[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ted Zlatanov
Subject: elpa.gnu.org repository sync with Emacs (was: rainbow-mode)
Date: Tue, 16 Nov 2010 07:50:48 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Mon, 15 Nov 2010 22:15:33 -0500 Glenn Morris <address@hidden> 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 <address@hidden> 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."


reply via email to

[Prev in Thread] Current Thread [Next in Thread]