From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MAINTAINERS file Date: Sat, 01 Mar 2008 11:27:00 +0200 Message-ID: References: <18375.18663.981150.252393@kahikatea.snap.net.nz> <87ir088d1y.fsf@red-bean.com> <18375.60094.959733.716249@kahikatea.snap.net.nz> <87skzb5r3l.fsf@red-bean.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1204363656 1544 80.91.229.12 (1 Mar 2008 09:27:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2008 09:27:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 10:28:01 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 1JVO0b-0004EK-KS for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2008 10:27:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVO04-0002jJ-F3 for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2008 04:27:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JVNzz-0002iu-0B for emacs-devel@gnu.org; Sat, 01 Mar 2008 04:27:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JVNzw-0002iE-6C for emacs-devel@gnu.org; Sat, 01 Mar 2008 04:27:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JVNzv-0002i2-Rk for emacs-devel@gnu.org; Sat, 01 Mar 2008 04:27:15 -0500 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JVNzv-000403-Et for emacs-devel@gnu.org; Sat, 01 Mar 2008 04:27:15 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-84-229-228-118.inter.net.il [84.229.228.118]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id KKB49873 (AUTH halo1); Sat, 1 Mar 2008 11:26:42 +0200 (IST) In-reply-to: <87skzb5r3l.fsf@red-bean.com> (message from Karl Fogel on Fri, 29 Feb 2008 17:34:54 -0500) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:90964 Archived-At: > From: Karl Fogel > Date: Fri, 29 Feb 2008 17:34:54 -0500 > Cc: emacs-devel@gnu.org > > 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. So in your case, the vote by the global committers is that ``someone'' whom Nick calls ``arbitrator''. Thus, ``this is not true'' above is, well, not true. > 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! :-) One evidence, maybe. > A power structure is not needed, when you have revision control (so > changes can be undone) and forkability (so dissenters are never > trapped). So you think that commit/revert wars and forks are a better alternative than clear, agreed-upon rules? > You might ask: what then is [Yidong's] and Stefan's role? > > Answer: default moral authority to prevent bandwidth-consuming votes > for every little dispute. By this, you actually suggested specific guidelines for managing the project. But these guidelines must be discussed and agreed to, in order for them to become Emacs project's guidelines rather than Karl Fogel's guidelines. Otherwise, why would you think that you and I see Yidong's and Stefan's leadership eye to eye? > There's no reason for us to put potentially costly dispute-resolution > structures in place in anticipation of problems that may never arise. How do you know it is ``potentially costly'' without hearing specific proposals, let alone trying them?