From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: elpa.gnu.org repository sync with Emacs Date: Tue, 16 Nov 2010 12:17:05 -0500 Message-ID: References: <87mxpabjj3.fsf@stupidchicken.com> <8762vyz5rl.fsf@stupidchicken.com> <8739r2z1w8.fsf@stupidchicken.com> <87y68t8jif.fsf_-_@lifelogs.com> <87r5eljosw.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289927896 17114 80.91.229.12 (16 Nov 2010 17:18:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Nov 2010 17:18:16 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 16 18:18:11 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 1PIPAX-0002En-ES for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2010 18:18:11 +0100 Original-Received: from localhost ([127.0.0.1]:37581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIPAU-0004b6-7I for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2010 12:18:06 -0500 Original-Received: from [140.186.70.92] (port=32818 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIP9l-00046P-Tr for emacs-devel@gnu.org; Tue, 16 Nov 2010 12:17:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIP9a-0007Eu-39 for emacs-devel@gnu.org; Tue, 16 Nov 2010 12:17:11 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:36667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIP9Z-0007EO-VL for emacs-devel@gnu.org; Tue, 16 Nov 2010 12:17:10 -0500 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id oAGHH7r7001177; Tue, 16 Nov 2010 12:17:07 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 5453F13002B; Tue, 16 Nov 2010 12:17:05 -0500 (EST) In-Reply-To: <87r5eljosw.fsf@stupidchicken.com> (Chong Yidong's message of "Tue, 16 Nov 2010 10:01:03 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3681=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:132735 Archived-At: >> 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