Re: elpa.gnu.org repository sync with Emacs

[Ted Zlatanov]

On Tue, 16 Nov 2010 10:01:03 -0500 Chong Yidong <address@hidden> wrote: 

CY> Ted Zlatanov <address@hidden> writes:
>> 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).

CY> I think it makes more sense to add elpa/ as a branch.  Then we can just
CY> `bzr merge' from savannah into the bzr repository used for elpa.gnu.org,
CY> in order to grab the changes made by Emacs devs.  (I don't think you can
CY> `bzr merge' a subdirectory, or can you?)

We would merge the whole Emacs repository into a repo on elpa.gnu.org.
But only the elpa/ subdirectory would get deployed out of that repo, the
rest would be there just to make the merge simpler.  I think that's the
easiest way.

As I said, I think a subdirectory will allow branching which in turn
will freeze the elpa/* packages for a particular version of Emacs
(instead of making special branches for that purpose).  That alone is
worth the price of admission.

CY> First, we should make a change to the elpa.gnu.org repository:
CY> currently, the .tar packages live in the repositories as tarballs.  We
CY> should instead leave them as untarred directories, and put the script on
CY> elpa.gnu.org in charge of tarring them up after `bzr export'.  That way,
CY> changes made to the contents of packages can be viewed with bzr
CY> diff.

No problem.  That would just be a "make elpa" command in each directory
and at the top.  I agree tarballs are a pain for tracking so this works
best.

CY> Still unresolved is the problem of which packages should be considered
CY> "OK" to tweak, and which should not.  I don't relish the idea of having
CY> to do a big merge every time a package is released upstream.  I think we
CY> should have a clear policy that only packages that are developed
CY> principally inside the package bzr repository, or whose maintainer is
CY> explicitly in charge of merging, should be hacked on.

How about a "third-party" package repository, disabled by default but
easily enabled, which would host externally hosted packages?

We would fetch truly external packages such as org-mode into it with
scripts, disconnected from the Emacs repo and the elpa.gnu.org
deployment.  And it would not be versioned: whatever is fetched today is
what you get.

That separates things nicely between "internal" and "external"
elpa.gnu.org packages, with "internal" packages coming from the Emacs
repo, versioned, and hacked regularly; "external" packages independent,
fetched regularly, and maintained outside of Emacs.

Ted