From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Reordering etc/NEWS Date: Fri, 11 May 2007 10:49:17 -0700 Message-ID: <87veez9roi.fsf@red-bean.com> References: <2wmz0iriyj.fsf@fencepost.gnu.org> <876470ekuz.fsf@red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1178905770 32347 80.91.229.12 (11 May 2007 17:49:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 May 2007 17:49:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 11 19:49:27 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 1HmZF7-0002yW-BG for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 19:49:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmZMY-00073M-MF for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 13:57:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmZMW-00073H-97 for emacs-devel@gnu.org; Fri, 11 May 2007 13:57:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmZMV-000735-L4 for emacs-devel@gnu.org; Fri, 11 May 2007 13:57:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmZMV-000732-IB for emacs-devel@gnu.org; Fri, 11 May 2007 13:57:03 -0400 Original-Received: from sanpietro.red-bean.com ([66.146.193.61]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HmZF2-0000pK-8C; Fri, 11 May 2007 13:49:20 -0400 Original-Received: from localhost ([127.0.0.1]:56179 ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.63) (envelope-from ) id 1HmZF0-0007wt-QP; Fri, 11 May 2007 12:49:19 -0500 In-Reply-To: (Eli Zaretskii's message of "Fri\, 11 May 2007 11\:50\:28 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux) X-detected-kernel: 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:70839 Archived-At: Eli Zaretskii writes: > Remember my message a day or two ago where I explained that Emacs > development needs experts in many different areas to be part of the > core team (those who can approve or reject patches)? You agreed with > that, I think. > > If we don't have enough experts, how can we make sure the release > branch remains stable? Someone needs to review patches suggested for > that branch and make sure they are safe. A single volunteer is not > very good in splitting her attention between two potentially very > different code bases, so many areas will need two people. And on top > of that, volunteers generally like new development much more than > maintenance-like activity one finds on release branches. > > That's the problem in always having an open trunk in Emacs: you need > roughly twice as many experts to handle a stable release branch and > the trunk at the same time. Right now, we don't even have a single > full team, let alone two. Those who are blocked from checking in new changes on trunk do not always then volunteer for release stabilization/maintenance work. I don't, for example, except in the packages that I maintain -- and that's work I would do anyway, regardless of whether I'm checking in new trunk code as well. (Don't most package maintainers behave this way, maintaining the things for which they've accepted responsibility regardless of what other work they're doing?) Zero-sum assumptions don't hold here. > If you ask me, I won't even consider going to the scheme you suggest > until the list of files in MAINTAINERS for which there's no > responsible individual is significantly reduced. Well, I think this is overestimating both the amount and the style of control one can really have with a group of volunteers... >> I've seen it work very well on other projects. > > Please name the largest project where it works very well, and let's > compare its size and the number of disjoint areas of expertise it > requires to those of Emacs. The largest I know of off the top of my head is Subversion, which is smaller than Emacs but also has very disjoint areas of expertise. (I'm not sure the dimensions of comparison you're proposing here are valid anyway, though; even if they were, my earlier point about how volunteers actually allocate their time still holds.) I think it may be moot now. Richard seems to have declared trunk open again. -Karl