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: MAINTAINERS file Date: Fri, 29 Feb 2008 17:34:54 -0500 Message-ID: <87skzb5r3l.fsf@red-bean.com> References: <18375.18663.981150.252393@kahikatea.snap.net.nz> <87ir088d1y.fsf@red-bean.com> <18375.60094.959733.716249@kahikatea.snap.net.nz> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204324710 14582 80.91.229.12 (29 Feb 2008 22:38:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Feb 2008 22:38:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 29 23:38:56 2008 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 1JVDsV-0001wR-4k for ged-emacs-devel@m.gmane.org; Fri, 29 Feb 2008 23:38:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVDry-0000c7-MF for ged-emacs-devel@m.gmane.org; Fri, 29 Feb 2008 17:38:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JVDoj-0006Bl-8b for emacs-devel@gnu.org; Fri, 29 Feb 2008 17:35:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JVDoe-000684-Ku for emacs-devel@gnu.org; Fri, 29 Feb 2008 17:35:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVDoe-00067t-HO for emacs-devel@gnu.org; Fri, 29 Feb 2008 17:34:56 -0500 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 1JVDoe-0005f0-J3 for emacs-devel@gnu.org; Fri, 29 Feb 2008 17:34:56 -0500 Original-Received: from localhost ([127.0.0.1]:60235 ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.68) (envelope-from ) id 1JVDoc-0000Zb-Rb; Fri, 29 Feb 2008 16:34:54 -0600 In-Reply-To: <18375.60094.959733.716249@kahikatea.snap.net.nz> (Nick Roberts's message of "Sat\, 1 Mar 2008 00\:21\:34 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: 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:90918 Archived-At: Nick Roberts writes: > Chaos is never favourable, although anarchy may sometimes be. Someone has > to always arbitrate over any disagreement. This is not true. For example, in the Subversion project there is no arbitrator. We try for consensus, and if there is unresolveable disagreement, the global committers vote. A vote has happened only twice in the history of the project: - To decide on the name of the command line binary ("sub" vs "svn") - To decide whether we would put a space before the opening parenthesis when writing C function calls and definitions. I think this is evidence that consensus, with democracy as a fallback, can work pretty well! :-) > > Let's wait until there's a problem before imposing a solution like > > this. > > Like what? There always has been a power structure for Emacs but I > guess up till now it's been so simple that it didn't need writing > down before. A power structure is not needed, when you have revision control (so changes can be undone) and forkability (so dissenters are never trapped). You might ask: what then is Chen and Stefan's role? Answer: default moral authority to prevent bandwidth-consuming votes for every little dispute. If enough of us grant them the right to make judgement calls (and I certainly intend to abide by their judgement when I'm unable to convince them of something), then the project will run efficiently and they will have the ability to enforce consistency on the codebase. This is the only authority RMS ever had, really. Being root on the repository and mailing list servers is not decisive: it cannot prevent a fork if people are determined to fork. The consent of the "governed" is the only thing that makes this work, in the end. It has done the job up till now, and I see no reason why it can't continue. There's no reason for us to put potentially costly dispute-resolution structures in place in anticipation of problems that may never arise. -Karl