From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Mon, 15 Nov 2010 19:53:37 +0100 Organization: Programmerer Ingebrigtsen Message-ID: References: <87mxpabjj3.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289847274 29244 80.91.229.12 (15 Nov 2010 18:54:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 18:54:34 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 15 19:54:29 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 1PI4C5-0004Dc-2p for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 19:54:21 +0100 Original-Received: from localhost ([127.0.0.1]:38287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI4C4-0000kS-MB for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 13:54:20 -0500 Original-Received: from [140.186.70.92] (port=54874 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI4Bh-0000aO-Qj for emacs-devel@gnu.org; Mon, 15 Nov 2010 13:54:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI4Bc-0006OM-28 for emacs-devel@gnu.org; Mon, 15 Nov 2010 13:53:57 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:39557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI4Bb-0006O0-LU for emacs-devel@gnu.org; Mon, 15 Nov 2010 13:53:51 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PI4BZ-0003th-Ra for emacs-devel@gnu.org; Mon, 15 Nov 2010 19:53:49 +0100 Original-Received: from cm-84.215.34.171.getinternet.no ([84.215.34.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Nov 2010 19:53:49 +0100 Original-Received: from larsi by cm-84.215.34.171.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Nov 2010 19:53:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 44 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.34.171.getinternet.no Mail-Copies-To: never X-Now-Playing: Wobbly, Matmos, Lesser's _Simultaneous Quodlibet_ User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:iJZ3Gmx+/CUpXXx/XTyzsHC3g3A= 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:132647 Archived-At: Chong Yidong writes: > 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). The reason that I raised the question now was that I was trying to figure out how to do reasonable colour distance calculations for rendering foreground colours in shr.el. rainbow-mode (for colourising colour specs in, for instance, CSS files) was brought up, that had similar needs, and its calculations in the same area might possibly be reusable by shr.el. But apparently rainbow-mode went to ELPA instead of into Emacs, even though it's small, it's clearly written, and it seems to be generally useful for anybody editing stuff like CSS or .Xdefaults files or anything. So I wondered why that was... > 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. If ELPA is supposed to be a repository of really special-needs code, I think it's a good idea. It would be nice to have an automatic way to download, say, one of the Emacs-based mp3 players. But if it's going to carry stuff that people do really want to have in the Emacs distribution, then I think it's counter-productive. Stuff that is in Emacs gets loving care. When url.el needs tweaking (for instance), people step up to the plate and makes sure that it works. Things that live in a package repository bit-rot at an alarming rate. One of the great things about Emacs is that when you "apt-get install emacs", you get a fully-featured system where you can be reasonably sure that things work. Over-modularisation can be costly in the long run. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen