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: rainbow-mode Date: Mon, 15 Nov 2010 23:06:34 -0500 Message-ID: <878w0t7vzp.fsf@stupidchicken.com> References: <87mxpabjj3.fsf@stupidchicken.com> <8762vyz5rl.fsf@stupidchicken.com> <8739r2z1w8.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1289880413 4299 80.91.229.12 (16 Nov 2010 04:06:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Nov 2010 04:06:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 16 05:06:48 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 1PICoi-00087X-Nm for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2010 05:06:48 +0100 Original-Received: from localhost ([127.0.0.1]:59629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PICoi-0005Di-9M for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 23:06:48 -0500 Original-Received: from [140.186.70.92] (port=42677 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PICoa-0005DX-KR for emacs-devel@gnu.org; Mon, 15 Nov 2010 23:06:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PICoZ-00089o-D9 for emacs-devel@gnu.org; Mon, 15 Nov 2010 23:06:40 -0500 Original-Received: from pantheon-po25.its.yale.edu ([130.132.50.119]:48213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PICoW-000896-UH; Mon, 15 Nov 2010 23:06:37 -0500 Original-Received: from furball (dhcp128036225159.central.yale.edu [128.36.225.159]) (authenticated bits=0) by pantheon-po25.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id oAG46ZWx028487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Nov 2010 23:06:35 -0500 Original-Received: by furball (Postfix, from userid 1000) id DB590160729; Mon, 15 Nov 2010 23:06:34 -0500 (EST) In-Reply-To: (Glenn Morris's message of "Mon, 15 Nov 2010 22:15:33 -0500") 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:132688 Archived-At: Glenn Morris writes: > I tried the elpa interface and it seems very nifty, but I do share the > concerns expressed about what it all means in practice for the > maintenance of the associated packages. As an "easy way to get a > package that would otherwise not be in Emacs" (eg AUCTeX), it seems > really nice; for farming out things that otherwise _would_ be in > Emacs proper, not so much. I hear you. Let's try to clarify the discussion. There are two classes of packages that could end up on elpa.gnu.org: (i) Small packages. Individually, each could be included in the tarball, but when the number of such small packages goes into the hundreds (*), this eventually becomes problematic. (ii) Big packages, like AUCTeX, big enough that including it in Emacs would be a momentous decision. Based on the discussion so far, I think we should give all Emacs hackers some kind of access to modify the packages. (For instance, we could set up a separate "dev-only" version of the package repository, which is occassionally merged into the "public usage" repository.) The problem is that if we Emacs hackers start tinkering with everything, the situation could be headache-inducing. At first glance, it seems like we should only feel free to modify the small packages, while leaving the big ones alone. But there have made many tweaks made to big packages built into Emacs, such as CEDET. These tweaks have to be dealt with when upstream is merged in, but that's life; they have been very important in making sure that Emacs works as a coherent whole. So my question is, do we really want to deal the same issues for AUCTeX and Muse and Company mode and whatever other big package ends up on elpa.gnu.org? This is not a rhetorical question; I don't know the answer.