From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: elpa.gnu.org repository sync with Emacs
Date: Tue, 16 Nov 2010 09:14:53 -0600 [thread overview]
Message-ID: <87oc9p711u.fsf@lifelogs.com> (raw)
In-Reply-To: 87r5eljosw.fsf@stupidchicken.com
On Tue, 16 Nov 2010 10:01:03 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:
CY> Ted Zlatanov <tzz@lifelogs.com> 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
next prev parent reply other threads:[~2010-11-16 15:14 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 15:40 ELPA policy Julien Danjou
2010-11-15 17:09 ` Chong Yidong
2010-11-15 18:53 ` Lars Magne Ingebrigtsen
2010-11-15 20:33 ` Chong Yidong
2010-11-15 21:41 ` rainbow-mode (was: ELPA policy) Lars Magne Ingebrigtsen
2010-11-15 21:52 ` Drew Adams
2010-11-15 22:06 ` rainbow-mode Lars Magne Ingebrigtsen
2010-11-16 5:11 ` rainbow-mode Stephen J. Turnbull
2010-11-16 13:25 ` rainbow-mode Lars Magne Ingebrigtsen
2010-11-16 14:03 ` rainbow-mode Ted Zlatanov
2010-11-16 14:22 ` rainbow-mode Lars Magne Ingebrigtsen
2010-11-16 14:44 ` rainbow-mode Ted Zlatanov
2010-11-16 14:50 ` rainbow-mode Lars Magne Ingebrigtsen
2010-11-16 15:05 ` rainbow-mode Ted Zlatanov
2010-11-16 15:53 ` rainbow-mode Julien Danjou
2010-11-16 15:39 ` rainbow-mode Drew Adams
2010-11-17 4:02 ` rainbow-mode Stephen J. Turnbull
2010-11-15 21:56 ` rainbow-mode Chong Yidong
2010-11-15 22:05 ` rainbow-mode Lars Magne Ingebrigtsen
2010-11-16 3:15 ` rainbow-mode Glenn Morris
2010-11-16 4:06 ` rainbow-mode Chong Yidong
2010-11-16 5:55 ` rainbow-mode Stefan Monnier
2010-11-16 13:50 ` elpa.gnu.org repository sync with Emacs (was: rainbow-mode) Ted Zlatanov
2010-11-16 15:01 ` elpa.gnu.org repository sync with Emacs Chong Yidong
2010-11-16 15:14 ` Ted Zlatanov [this message]
2010-11-16 17:28 ` Stefan Monnier
2010-11-16 18:10 ` Ted Zlatanov
2010-11-16 19:14 ` Stefan Monnier
2010-11-16 19:40 ` Ted Zlatanov
2010-11-16 20:02 ` Chong Yidong
2010-11-16 21:21 ` Ted Zlatanov
2010-11-16 17:17 ` Stefan Monnier
2010-11-16 18:00 ` Lars Magne Ingebrigtsen
2010-11-16 18:05 ` Ted Zlatanov
2010-11-16 18:11 ` Lars Magne Ingebrigtsen
2010-11-17 8:01 ` AUCTeX inclusion [Re: elpa.gnu.org repository sync with Emacs] Dan Nicolaescu
2010-11-17 15:00 ` Ted Zlatanov
2010-11-18 4:25 ` Dan Nicolaescu
2010-11-19 6:16 ` Richard Stallman
2010-11-20 7:45 ` Dan Nicolaescu
2010-11-20 8:20 ` David Kastrup
2010-11-22 14:56 ` Ted Zlatanov
2010-11-16 18:29 ` elpa.gnu.org repository sync with Emacs Eric Schulte
2010-11-16 19:00 ` Ted Zlatanov
2010-11-16 20:32 ` Eric Schulte
2010-11-17 19:29 ` Richard Stallman
2010-11-17 19:45 ` Drew Adams
2010-11-17 20:58 ` Ted Zlatanov
2010-11-17 22:19 ` Lars Magne Ingebrigtsen
2010-11-19 6:16 ` Richard Stallman
2010-11-17 23:17 ` Jambunathan K
2010-11-17 23:34 ` Jambunathan K
2010-11-18 15:40 ` Ted Zlatanov
2010-11-20 10:05 ` Byung-Hee HWANG
2010-11-20 15:26 ` Drew Adams
2010-11-22 14:47 ` Ted Zlatanov
2010-11-22 16:47 ` Chong Yidong
2010-11-22 18:48 ` Ted Zlatanov
2010-11-23 17:19 ` Richard Stallman
2010-11-23 17:58 ` Drew Adams
2010-11-22 16:48 ` Stefan Monnier
2010-11-18 0:01 ` Stefan Monnier
2010-11-18 21:27 ` Drew Adams
2010-11-16 19:10 ` Stefan Monnier
2010-11-16 19:24 ` Stefan Monnier
2010-11-16 19:44 ` Tom Tromey
2010-11-16 20:21 ` Lars Magne Ingebrigtsen
2010-11-16 21:37 ` Ted Zlatanov
2010-11-16 21:41 ` Lars Magne Ingebrigtsen
2010-11-17 4:04 ` Stephen J. Turnbull
2010-11-15 21:06 ` ELPA policy Edward O'Connor
2010-11-16 3:26 ` Glenn Morris
2010-11-15 17:27 ` elpa.gnu.org policy (was: ELPA policy) Ted Zlatanov
2010-11-15 18:01 ` elpa.gnu.org policy Lluís
2010-11-15 18:43 ` Ted Zlatanov
2010-11-15 20:19 ` Chong Yidong
2010-11-15 21:46 ` Lars Magne Ingebrigtsen
2010-11-15 22:06 ` Tom Tromey
2010-11-15 22:20 ` Chong Yidong
2010-11-15 22:29 ` Lars Magne Ingebrigtsen
2010-11-16 4:03 ` Glenn Morris
2010-11-16 13:31 ` Lars Magne Ingebrigtsen
2010-11-16 14:10 ` compat unification (was: elpa.gnu.org policy) Lars Magne Ingebrigtsen
2010-11-16 15:31 ` compat unification Stefan Monnier
2010-11-16 15:44 ` Lars Magne Ingebrigtsen
2010-11-16 22:20 ` Glenn Morris
2010-11-16 15:56 ` elpa.gnu.org policy Drew Adams
2010-11-15 18:50 ` ELPA policy Tom Tromey
2010-11-15 22:10 ` Glenn Morris
2010-11-15 19:35 ` Stefan Monnier
2010-11-15 20:12 ` Chong Yidong
2010-11-15 21:59 ` Ted Zlatanov
2010-11-16 21:23 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87oc9p711u.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).