[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new Emacs maintainer(s)?

From: David Kastrup
Subject: Re: new Emacs maintainer(s)?
Date: Wed, 06 Jun 2007 12:54:35 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
> My ideal setup would be:
> Emacs 22.x (maintenance): Richard (who can still pull on anyone to
> actually merge/adapt desired fixes from the trunk to the 22.x
> branch).

Funny: that would be pretty much my worst case scenario since Richard
is primarily a manager of people (his intermittent access does not
make much more possible, anyway), and pulling on anyone is going to
detract "anyone" from ongoing work on the trunk.  The admirable
ability to unceremoniously come through with the technical changes
once the direction is clear, is what made me propose Chong: he made
quite a lot of progress even in a zigzag course dictated by changing
opinions and policies.  If he is going to set the policies himself, he
will save himself a few dead ends.

> Emacs 23.1: A committee of Handa [technical lead], Chong [release
> manager], and a third person (e.g. Stefan).

Well, Handa is already the technical lead of unicode-2 and somewhat
biased.  It is clear anyway that he'll be needed to iron out quite a
number of pains in connection with unicode-2, and I would not find it
amiss if there was a somewhat less "partial" person involved with
judging the severity of changes in the API to the general developer
public.  Chong does not make the impression to me of being scared of
complexity.  But I am, and I would like somebody who is conservative
(though not in a destructive way) to counterbalance the unicode-2

> Emacs 23.x (maintenance): One of the above (or somebody else ?)

Probably too early to think about that.

> Emacs 24.1: A committee of Eli [technical lead], ? [release
> manager], and a third person (perferably someone with interest in
> BIDI).

What I wrote above for Emacs 23.1 with regard to Handa would apply for
24.1 and Eli similarly.  While it is clear that those are
indispensable for the work in question, I'd prefer having a
counterweight in the project leadership.  This would also make it
possible for them to argue their case without having to be impartial
about it: it would be the job of the respective version leader to
weigh their needs against those of others.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]