From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Mon, 21 Jan 2008 11:00:41 +0100 Message-ID: <87odbfo5va.fsf@ambire.localdomain> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <4pd9g15e.fsf@blue.sea.net> <874pd92ias.fsf@catnip.gol.com> <87y7al11a1.fsf@catnip.gol.com> <87fxwraon5.fsf@red-bean.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1200911203 29439 80.91.229.12 (21 Jan 2008 10:26:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Jan 2008 10:26:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 21 11:27: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 1JGtrl-0004Xs-Im for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2008 11:26:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JGtrJ-0003SA-A7 for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2008 05:26:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JGtos-0002p5-VN for emacs-devel@gnu.org; Mon, 21 Jan 2008 05:23:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JGtor-0002nv-33 for emacs-devel@gnu.org; Mon, 21 Jan 2008 05:23:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JGtoq-0002nd-GW for emacs-devel@gnu.org; Mon, 21 Jan 2008 05:23:56 -0500 Original-Received: from ppp-100-38.21-151.libero.it ([151.21.38.100] helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JGtop-0000k7-P5 for emacs-devel@gnu.org; Mon, 21 Jan 2008 05:23:56 -0500 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1JGtSL-0002CY-TM for emacs-devel@gnu.org; Mon, 21 Jan 2008 11:00:41 +0100 In-Reply-To: (Glenn Morris's message of "Sun, 20 Jan 2008 22:16:05 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:87203 Archived-At: () Glenn Morris () Sun, 20 Jan 2008 22:16:05 -0500 Is anyone trying to tell me, that switching to some hip new version control system is going to make people start applying the patches that currently sit around in this mailing list for weeks? Although i haven't in the past, i would be willing to tell you that, and will take time to explain why, now: Emacs hacking requires thought to "DTRT", which is inhibiting to me because experience leads me to ponder (mostly enjoyably, but more germainely, always lengthily) on the history of the context of that acronym as uttered by a specific person, to avoid getting burned by misunderstanding. When rms sez "DTRT", i work hard to disambiguate its meaning from when jrhacker sez "DTRT". Perhaps others find it easier; i cannot speak for others. A distributed version control system (my bias is towards git at the moment) separates DTRT_process from DTRT_code up to the time of publishing the change. The effect is that i can parallelize my pondering to some (Amdahl-limited ;--) extent, and thus check in things faster. Now let's turn from commit 0 in a series, to commit N. Why is there a commit N? Because commit 0 was problematic in some way, even though supreme effort was (presumably) expended to DTRT. i.e, commit 0 did NOT DTRT; i make mistakes, i misunderstand. A distributed version control system would mitigate this by letting me do commit 0 locally, iterating N times until my practice matches what is considered to be TRT. This is basically a restatement of the parallelized pondering paragraph above, w/ s/understanding/practice/g. "But", you may be thinking, "what does that have to do w/ patches that have been sitting around for weeks?" Well, i have write privs and i am happy to check in code that DTRT from those that do not have write privs. But how do i know that code DTRT? How do i know its author has iterated enough so that the understanding/practice reflected therein has the quality of commit N and not quality of commit 0? One answer to these questions starts w/ "It's none of your business; why do you care?; your part is merely secretarial." To which i can only say: sorry, i do care, and will ignore arguments in that vein. Another answer is: "Learn the code; use the opportunity of its passing through your brain to expand your expertise -- in that way you will recognize if it DTRT." To which i say: agreed mostly, but not fully. I can expand my understanding of such code, per se, but w/o access to its history, the understanding is illusory and incomplete. There is a chance that i have merely stumbled upon a superficial outcropping of deeper (more interesting) issues, that my grokking is mere luck, and most dangerously, that the overlapped (between myself and the code's author) grokking is transitory. "Looks good because of X", thinks ttn. "*IS* good because of Y", thinks its author. Patch applied. Fast-forward two months; ttn hacks on the code to support X better, breaking Y. Lose. IMHO expanding my expertise is best done by building on the expertise of others. A distributed version control system combined w/ people's disinhibition of exposing their mistakes allows me to more quickly grok the thought that went into the presented patch as well as the code it changes, align my thoughts w/ it, iterate w/ the author as necessary to achieve quality of commit N, and apply it. In the end, my spewing here might seem like an indictment of DTRT. Perhaps. But i tend to think otherwise: i think "DTRT" ethos needs to grow up and leave the nest. This involves two things: supporting a phase separation of D and TRT, and expansion of TRT to not only accept mistakes, but to actively support archeological non-punitive reflection on the actions that surround them. thi