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 policy Date: Mon, 15 Nov 2010 12:09:52 -0500 Message-ID: <87mxpabjj3.fsf@stupidchicken.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289841109 30545 80.91.229.12 (15 Nov 2010 17:11:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 17:11:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 15 18:11:45 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 1PI2af-0006yn-Q5 for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 18:11:44 +0100 Original-Received: from localhost ([127.0.0.1]:56572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI2aX-0001Tl-CU for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 12:11:29 -0500 Original-Received: from [140.186.70.92] (port=54106 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI2Z7-0000fS-GA for emacs-devel@gnu.org; Mon, 15 Nov 2010 12:11:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI2Z1-0001Lu-0Z for emacs-devel@gnu.org; Mon, 15 Nov 2010 12:09:59 -0500 Original-Received: from pantheon-po26.its.yale.edu ([130.132.50.121]:47434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI2Z0-0001LY-Ug for emacs-devel@gnu.org; Mon, 15 Nov 2010 12:09:54 -0500 Original-Received: from furball (dhcp128036014113.central.yale.edu [128.36.14.113]) (authenticated bits=0) by pantheon-po26.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id oAFH9r49006149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Nov 2010 12:09:54 -0500 Original-Received: by furball (Postfix, from userid 1000) id CFDF51605A6; Mon, 15 Nov 2010 12:09:52 -0500 (EST) In-Reply-To: (Julien Danjou's message of "Mon, 15 Nov 2010 16:40:39 +0100") 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:132640 Archived-At: Julien Danjou writes: > I am currently worried by the Emacs ELPA archive and what will be that > policy. As Lars pointed out, until now, packages have been added over > the years into Emacs trunk, maintained by a extended set of skilled > hands, assuring good quality in (almost :-)) every place of every > packages furnished with Emacs. Emacs contains many packages that are maintained "externally". While Emacs developers might make small changes to the in-tree version, most development is done upstream and periodically merged in. Those upstream maintainers handle bugfixes and ensure compatibility among Emacs versions. One good reason to put a package in elpa.gnu.org, rather than in the Emacs tarball, is if it is likely to benefit only a small segment of Emacs users (even if it's of tremendous usefulness to that segment). Especially, but not necessarily, if a package is large and complex, like Auctex and Muse. There are other good reasons too, e.g. packages that we want to merge into Emacs core in the future, but not yet (for whatever reason). (Incidentally, there are also some packages in Emacs that might be usefully moved out into elpa.gnu.org, e.g. since they are so rarely used. We could also move some of the files in obsolete/ into a subrepository, e.g. elpa.gnu.org/packages/obsolete) (Also, as stated before, the FSF's policy is that for a package to be listed on elpa.gnu.org its copyright must be assigned, in the exact same way as if it's included in Emacs core.) > - Who will be able to upload to ELPA? > - Who will assure there's no really bad things uploaded? The way it's currently set up is that only a couple of people can upload to ELPA; package maintainers, when they release a new version, should email me (or Ted) to get the package uploaded. The system is still a work in progress; we might set up a more elaborate "staging area" system in the future. (Such a system would still involve a human component, of course, to reduce the possibility of malicious uploads.) I will add a page to the elpa.gnu.org webpage explaining this.