From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: elpa.gnu.org repository sync with Emacs Date: Tue, 16 Nov 2010 10:01:03 -0500 Message-ID: <87r5eljosw.fsf@stupidchicken.com> References: <87mxpabjj3.fsf@stupidchicken.com> <8762vyz5rl.fsf@stupidchicken.com> <8739r2z1w8.fsf@stupidchicken.com> <87y68t8jif.fsf_-_@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289919878 7198 80.91.229.12 (16 Nov 2010 15:04:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Nov 2010 15:04:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 16 16:04:34 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PIN5E-000446-1q for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2010 16:04:32 +0100 Original-Received: from localhost ([127.0.0.1]:35721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIN5D-00032w-6J for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2010 10:04:31 -0500 Original-Received: from [140.186.70.92] (port=42044 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIN2M-00012t-JQ for emacs-devel@gnu.org; Tue, 16 Nov 2010 10:01:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIN2L-0006Mq-9P for emacs-devel@gnu.org; Tue, 16 Nov 2010 10:01:34 -0500 Original-Received: from pantheon-po41.its.yale.edu ([130.132.50.98]:59565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIN2L-0006Md-7a for emacs-devel@gnu.org; Tue, 16 Nov 2010 10:01:33 -0500 Original-Received: from furball (dhcp128036014177.central.yale.edu [128.36.14.177]) (authenticated bits=0) by pantheon-po41.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id oAGF1Vaq032182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 10:01:32 -0500 Original-Received: by furball (Postfix, from userid 1000) id 829C916086B; Tue, 16 Nov 2010 10:01:03 -0500 (EST) In-Reply-To: <87y68t8jif.fsf_-_@lifelogs.com> (Ted Zlatanov's message of "Tue, 16 Nov 2010 07:50:48 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132717 Archived-At: Ted Zlatanov 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). 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. (I don't think you can `bzr merge' a subdirectory, or can you?) 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. 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.