Re: elpa.gnu.org repository sync with Emacs

[Stefan Monnier]

>> 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).

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

200% agreement.

> (I don't think you can `bzr merge' a subdirectory, or can you?)

If you want to you can, but it's poorly supported by Bazaar, and in any
case we don't want to do that (if for nothing else, so as to avoid
imposing the slowness of Emacs's repository to the elpa repository).

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

Yes, obviously.

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

All packages should be OK to hack on.  And all commits should be
reflected on emacs-diffs (or maybe emacs-packages-diffs) *as well as*
sent to the respective upstream maintainer.
And all maintainers will be in charge of merging (which may include
rejecting a change we've made, of course).

What's the difference between this and packages that are bundled, then?
The difference is that we know for sure that the upstream maintainer
automatically gets an email for each one of our changes (i.e. he is
proactively warned of such changes), and also we know that the package
needs to pay attention to backward compatibility, so we have to be more
careful with the changes we install there.


        Stefan