From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Gregory Collins Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Mon, 07 Jan 2008 19:25:45 -0500 Message-ID: References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> <87fxxfnrhi.fsf@catnip.gol.com> <87d4sdte71.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199752003 11419 80.91.229.12 (8 Jan 2008 00:26:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2008 00:26:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 08 01:27:03 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 1JC2Iy-0003nw-HO for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2008 01:26:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JC2Ib-0000dq-Gs for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2008 19:26:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JC2Hs-0000Ma-Eb for emacs-devel@gnu.org; Mon, 07 Jan 2008 19:25:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JC2Hq-0000Lk-Mi for emacs-devel@gnu.org; Mon, 07 Jan 2008 19:25:48 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JC2Hq-0000Lf-Hf for emacs-devel@gnu.org; Mon, 07 Jan 2008 19:25:46 -0500 Original-Received: from subrosa.ca ([207.210.221.19]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JC2Hq-00037f-7I for emacs-devel@gnu.org; Mon, 07 Jan 2008 19:25:46 -0500 Original-Received: from greg by subrosa.ca with local (Exim 4.43) id 1JC2Hp-0002S0-7i; Mon, 07 Jan 2008 19:25:45 -0500 In-Reply-To: <87d4sdte71.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 08 Jan 2008 08:21:06 +0900") User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:86535 Archived-At: "Stephen J. Turnbull" writes: > Thus I suggest that the project workflow discussion be postponed until > the core stakeholders are satisfied that the new tools are functioning > stably in the current workflow. This will take only a month, at most > two, once the tools are chosen. As you point out, a big advantage of > a dVCS is the flexibility of the workflow even after it is installed. > There is no big loss to waiting a bit, and a potential large gain: the > improved understanding of the tools that the core stakeholders will > have. Hi Stephen, My remarks weren't meant to urge any immediate course of action, but rather to attempt to broaden the discussion to include possible answers to the question "why would you bother switching?" A discussion that centres on "how do these CVS concepts map to a distributed context?" will tend to obscure the most compelling arguments in favour. Clearly nothing is going to happen in a rush here (nor should it), because even if it's decided that the horse needs a cart, it's going to take months to decide a) what kind of cart b) two wheels or four? c) metal, wood, or composite? d) "what's wrong with saddlebags, anyways?" e) "You guys are soft, I walk everywhere, barefoot" f) "I live in Nunavut, so it's VERY IMPORTANT that the cart have optional skis" ... ad infinitum ... > > 2. "Lieutenant" / "subsystem percolation" > > ------------------------------------------ > > ... > > This is the only workflow that can scale with a lack of a formal > testing framework, but then it doesn't scale for the *people*. It is > incredibly hard on the maintainers, and is only really justified where > automated testing is hard to do. Agreed. > > 3. Mailing list w/ gatekeeper(s) > > --------------------------------- > > ... > > You're missing an important point: the sheer size and complexity of > the Emacs codebase. This requires more *formal* attention to testing > than Emacs has historically given it. The problem is that in the > Emacs context, a *good* review by the gatekeeper requires a huge stock > of knowledge of the codebase plus great expense on *each* patch. > Guido van Rossum estimates that a "perfect patch" nonetheless costs > him 30-60 minutes, but this is in a context of test-driven > development. In Emacs as it stands it will be much greater per patch. If it's a choice between "60 minutes per patch" and "little or no code review at all", I think everyone will agree that the review wouldn't happen. "Formality of code review" is a continuum, however, and it's my experience that you can stop a lot of bugs without pulling out the magnifying glass and tweezers. You may be right that the extreme hairiness of emacs code may invalidate that assumption. I'd argue regardless that the more eyeballs you can get on incoming patches, the better. I'd also argue that despite some impetuous claims to the contrary, the reports of emacs' imminent demise are greatly exaggerated. G.