From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: new Emacs maintainer(s)? Date: Wed, 06 Jun 2007 10:45:18 +0200 Message-ID: <86y7ixjwtd.fsf@lola.quinscape.zz> References: <878xb05ras.fsf@stupidchicken.com> <200706041853.l54IrLXb006451@oogie-boogie.ics.uci.edu> <200706051632.l55GWNSZ026462@oogie-boogie.ics.uci.edu> <87ps4aue45.fsf@stupidchicken.com> <87fy55cy7v.fsf@kfs-lx.testafd.dk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181119550 31446 80.91.229.12 (6 Jun 2007 08:45:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2007 08:45:50 +0000 (UTC) To: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 06 10:45:46 2007 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.50) id 1Hvr9E-0005il-Ik for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2007 10:45:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hvr9D-0004YX-5f for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2007 04:45:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hvr90-0004Uc-M8 for emacs-devel@gnu.org; Wed, 06 Jun 2007 04:45:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hvr8w-0004TT-Na for emacs-devel@gnu.org; Wed, 06 Jun 2007 04:45:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hvr8w-0004TQ-Kk for emacs-devel@gnu.org; Wed, 06 Jun 2007 04:45:26 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hvr8u-0002v0-NZ for emacs-devel@gnu.org; Wed, 06 Jun 2007 04:45:25 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id KAA04787 for ; Wed, 6 Jun 2007 10:45:17 +0200 X-Delivered-To: Original-Received: (qmail 6482 invoked from network); 6 Jun 2007 08:45:18 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 6 Jun 2007 08:45:18 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id A2A788F8EB; Wed, 6 Jun 2007 10:45:18 +0200 (CEST) In-Reply-To: <87fy55cy7v.fsf@kfs-lx.testafd.dk> (Kim F. Storm's message of "Wed\, 06 Jun 2007 09\:56\:52 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) X-detected-kernel: 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:72318 Archived-At: storm@cua.dk (Kim F. Storm) writes: > Chong Yidong writes: > >> However, if no one else wants to maintainer, I would not mind doing >> it; I think I shall have enough spare time to devote to this, at least >> during the next three or four years. > > Is that for 22.x only, or 23.1 ? > > In any case, you have my full support! I am not sure whether it is a good idea to discuss this sort of personals question on the list: after all, the decision rests with Richard, so we don't want to get hopes up only to have disappointment afterwards. On the other hand, of course I can't resist mouthing off about something like that, either... Here would be my scheme for an ideal setup: 22.x principal maintainer: Chong. Reason: we want to invest minimal man- and mindpower into 22.x and rather move forward. Chong has a history with 22.x across the board for and with pulling through with technical decisions (even though he did not make most of them on his own) even on code with which he has not had a long acquaintance. He keeps reasonably on top of things, so he is a pretty good candidate for merging appropriate fixes from the trunk. If 22.x were in the hands of Chong, I would have little qualms about moving the trunk to emacs-unicode2 pretty much right away (well, I wouldn't, anyway, but in this case I would be rather confident about the consequences). The downside would be mostly for Chong himself: it is to be expected that people indeed will leave 22.x mostly in his hands. However, if the decisions to make are mostly in his hands, too, it is likely that he'll be able to work more efficiently than when he is "on a leash". And if he can dispense with the 22.x work efficiently and in his own manner, it might not even take the bulk of his energy and time. 23.x principal maintainer: more difficult. We want to have a maintainer that makes working on Emacs fun while still keeping the "party line" of the GNU Project. Maybe splitting this into a technical lead and a policy supervisor would make sense. Could be an option to leave the latter somewhat ungrateful job to Richard. For the technical lead, at least for part of the way, we want someone who has familiarity with emacs-unicode-2 though it need not be his primary focus. We also want to get to the release at some point of time. I guess that my personal favorite here would actually be Kim, mostly because he has pretty much managed to keep out of the release spats in spite of his experience and seems well enough in contact with much code, including the display engine. Which could help for gathering the impetus for Emacs 24 (the one with bidirectional language support for which there is considerable demand by users that are pretty much out in the cold for now). Now of course this kind of setup will depend on the people actually being willing and able to step up to that kind of responsibility. Of course, there is a list of candidates who certainly would have enough authority and competence to pull through with the requirements. That was just my first thought on the "wouldn't it be nice if" scale. -- David Kastrup