From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Mon, 15 Nov 2010 15:59:43 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87hbfi9rjk.fsf@lifelogs.com> References: <87eiamz6qo.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289858415 19741 80.91.229.12 (15 Nov 2010 22:00:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 22:00:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 15 23:00: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 1PI75v-0003GT-Ii for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 23:00:11 +0100 Original-Received: from localhost ([127.0.0.1]:55912 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI75v-0005Eu-7w for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 17:00:11 -0500 Original-Received: from [140.186.70.92] (port=41104 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI75o-0005EV-At for emacs-devel@gnu.org; Mon, 15 Nov 2010 17:00:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI75j-0007jL-RR for emacs-devel@gnu.org; Mon, 15 Nov 2010 17:00:04 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:32773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI75j-0007j4-Fn for emacs-devel@gnu.org; Mon, 15 Nov 2010 16:59:59 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PI75d-000360-ES for emacs-devel@gnu.org; Mon, 15 Nov 2010 22:59:53 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Nov 2010 22:59:53 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Nov 2010 22:59:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 53 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:yZLTdO3+La4k+6WiLjpyUdgCg70= 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:132669 Archived-At: On Mon, 15 Nov 2010 15:12:15 -0500 Chong Yidong wrote: CY> Stefan Monnier writes: >> For new packages, I'd expect only a few people to have such rights, >> but for updates, I'd expect something like "anybody with access to the >> Bzr repository". After all, if they can screw with the main Emacs >> codebase, why not with the ELPA packages. CY> One difference, though, is that screwing with the main Emacs codebase CY> affects only those using the development version of Emacs, and we have CY> mechanisms like the diffs mailing list for problems to be easily CY> spotted. After Emacs 24 is released, by screwing with elpa.gnu.org you CY> can immediately affect users of deployed stable Emacs versions. CY> So, we need to be a bit more paranoid for elpa.gnu.org than for our main CY> repository. This is one good reason to keep a separate repository per major Emacs version, at least. Then you can fix packages without so much fear. CY> I agree, though, that it would be nice for Emacs developers to easily CY> edit packages in elpa.gnu.org without going through an onerous package CY> upload process. I'm not sure how to set this up, though maybe the way CY> the Org daily builds are handled can be used as a starting point. I hope we make it easy to submit changes but harder to publish them. See below for my staging suggestion. CY> Maintaining a separate repository for every Emacs release sounds like a CY> lot of work. Currently, it's up to maintainers of upstream/external CY> packages ensure backward compatibility with older Emacs versions, CY> e.g. by introducing compatibility functions. Obviously this system CY> doesn't work perfectly, but it doesn't seem like we have the manpower CY> for anything more elaborate. Setting it up is really not hard, even if we don't use it. Just add "packages-MAJOR" and "packages-MAJOR.MINOR" to the default "packages" repository on startup. Those can be empty but when we need something in them (and we will, I promise you), they'll Just Work. The dev checkout version should also have "packages-dev" or some such that's only enabled if you make a dev build. All this is not hard if we use VCS branches. It's a 1-to-1 mapping to the Emacs repo's branches. In fact the elpa.gnu.org repo could mirror a subdirectory of the Emacs repo, which would solve the staging problem (developers would just stage to the Emacs repo and the elpa.gnu.org maintainers would publish from there). I think the alternative approach, keeping it really simple now, will require more manpower and drain more time long-term. Ted