From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.devel Subject: Re: rainbow-mode Date: Mon, 15 Nov 2010 22:15:33 -0500 Message-ID: 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; charset=us-ascii X-Trace: dough.gmane.org 1289877355 26993 80.91.229.12 (16 Nov 2010 03:15:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Nov 2010 03:15:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 16 04:15: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 1PIC1K-0008EE-HJ for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2010 04:15:46 +0100 Original-Received: from localhost ([127.0.0.1]:45525 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIC1J-0007Wm-TT for ged-emacs-devel@m.gmane.org; Mon, 15 Nov 2010 22:15:46 -0500 Original-Received: from [140.186.70.92] (port=35015 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIC1B-0007TZ-AO for emacs-devel@gnu.org; Mon, 15 Nov 2010 22:15:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIC1A-0000Bj-4e for emacs-devel@gnu.org; Mon, 15 Nov 2010 22:15:37 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:45891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIC1A-0000Bd-2t for emacs-devel@gnu.org; Mon, 15 Nov 2010 22:15:36 -0500 Original-Received: from localhost ([127.0.0.1]:46150) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PIC17-0001Kt-Vu; Mon, 15 Nov 2010 22:15:34 -0500 X-Spook: industrial intelligence UFO passwd Israel CDC Yukon SEAL X-Ran: 0l-bR~:en[~5$i;gR`Vp}[zEl~[WT:19VB>7$T3hyl{4e@PYS5..>0[Q`+b.m?(FrL(2=u X-Hue: black X-Attribution: GM User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) 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:132685 Archived-At: Chong Yidong wrote: > as Stefan says, all things being equal, it is preferable to put new > non-infrastructure packages into elpa.gnu.org. This is a pretty big change in policy, IMO. Who's going to maintain these things? Where do the bug reports go? If it were in Emacs proper, I could and would (maybe) be fixing any bugs in it, improving docs, etc. If it's in elpa.gnu.org, I'm unlikely to ever even look at the code. And if I did and wanted to change something, all I have is a tarfile (no?), the repository lives somewhere else, and I'm unlikely to bother seeking it out, submitting a patch, etc. 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. Some of these issues would go away if these "non-infrastructure" packages (not AUCTeX etc, but rather the things that would have been added to Emacs before elpa) were hosted in a central Savannah bzr repository (or possible as a subdirectory in the existing Emacs repository that is excluded from the tarfiles; I'm not sure if the number of files in the Bzr version of Emacs matters very much), so that the Emacs developers can and do feel able to help maintain them. >From my point of, the ideal thing would be something like a separate top-level "elpa/" directory in the normal repo, not compiled by default, that I could compile with `make elpa' or somesuch. Then putting something on elpa doesn't mean relegating it to being a second-class citizen.