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 15:33:18 -0500 Message-ID: <8762vyz5rl.fsf@stupidchicken.com> References: <87mxpabjj3.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289854679 1505 80.91.229.12 (15 Nov 2010 20:57:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Nov 2010 20:57:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 15 21:57:55 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 1PI67f-0003fW-3i for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 21:57:55 +0100 Original-Received: from localhost ([127.0.0.1]:36949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI67e-0002Ur-Nb for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 15:57:54 -0500 Original-Received: from [140.186.70.92] (port=54954 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI60j-0005vL-3P for emacs-devel@gnu.org; Mon, 15 Nov 2010 15:50:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI5jv-0003cS-48 for emacs-devel@gnu.org; Mon, 15 Nov 2010 15:33:28 -0500 Original-Received: from pantheon-po26.its.yale.edu ([130.132.50.121]:45020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI5jv-0003cI-15 for emacs-devel@gnu.org; Mon, 15 Nov 2010 15:33:23 -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 oAFKXLCB004374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Nov 2010 15:33:22 -0500 Original-Received: by furball (Postfix, from userid 1000) id 0416E1605A6; Mon, 15 Nov 2010 15:33:18 -0500 (EST) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 15 Nov 2010 19:53:37 +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:132651 Archived-At: Lars Magne Ingebrigtsen writes: > 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... Rainbow-mode, as presented, is a tool for colorizing strings in Emacs buffers, the kind of neat hack that doesn't really need to be in Emacs. >From your description, it sounds like parts of it can be usefully refactored into a general color-manipulation library, in which case we could include that part in Emacs (preferably, using a better prefix than `rainbow'). > 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. Things that live in a package repository > bit-rot at an alarming rate. Well, obviously it's going to be a judgement call, analogous to the debates about what goes into distribution DVDs (with programs like Emacs nowadays frequently not making the cut :-P). The level of bit-rot is dependent on the upstream package maintainers; I don't think you can argue that packages like Auctex (or SLIME or ESS, which are not packaged) have bit-rotted. Some packages integrated into Emacs are no longer active upstream but are still tinkered with by Emacs developers, but what's really happening here is that we have effectively forked the project. If a package on elpa.gnu.org ends up being abandoned, there's little difference in how we could solve the problem, except the fork would be more explicit than implicit.