From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Tue, 08 Jan 2008 08:21:06 +0900 Message-ID: <87d4sdte71.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> <87fxxfnrhi.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199747803 31803 80.91.229.12 (7 Jan 2008 23:16:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Jan 2008 23:16:43 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Gregory Collins Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 08 00:17: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 1JC1DD-0000tp-72 for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2008 00:16:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JC1Cq-0007Yw-30 for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2008 18:16:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JC1Cl-0007Yd-5v for emacs-devel@gnu.org; Mon, 07 Jan 2008 18:16:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JC1Cj-0007YH-L7 for emacs-devel@gnu.org; Mon, 07 Jan 2008 18:16:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JC1Cj-0007YE-FV for emacs-devel@gnu.org; Mon, 07 Jan 2008 18:16:25 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JC1Cf-00082t-Jt; Mon, 07 Jan 2008 18:16:22 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id AAC671535A8; Tue, 8 Jan 2008 08:16:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B61E91A29E5; Tue, 8 Jan 2008 08:21:07 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" (+CVS-20071205) XEmacs Lucid 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:86530 Archived-At: Gregory Collins writes: > To make this more concrete, here are some commonly-used workflow models: I think this discussion is premature. Richard has indicated that he is satisfied that the Hippocratic Principle ("First, do no harm") *can* be satisfied by both a bug tracker and a dVCS. Further, he acknowledges that their potential benefits are significant *in the current workflow*. However, he expresses reservations that particular tools may still be detrimental to the Emacs project's productivity, if badly implemented. He's absolutely right. 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. This doesn't mean that those who want to implement other workflows have to wait, with nothing to do. Find other developers of like mind and start experimenting "off the main workflow". Cf. Miles's Arch repo, which is already providing substantial efficiencies in branch synchronization. I'm sure David Kastrup, for another, will be able to use a dVCS to good effect in supporting AUCTeX (which AIUI cannot yet be merged into Emacs because of legal considerations). Regarding the example workflows: > 1. CVS-style / star topology > ---------------------------- > There is a centralized "one true repository" at a known location > (e.g. http://savannah.gnu.org/.../hg/emacs-trunk). A medium-sized group > of hackers have "push" rights there. (It's the "push" that alters the > trunk here.) > > This approach doesn't scale well, although for emacs the commit rate is > probably low enough that this topology is manageable. (That said, how > many times have you asked "who committed this wonky change that broke > X?" this year?) At Emacs scale, the scaling problem here is the combination of lack of a testing framework and the star topology, not just the star topology. Python does fine with a star topology at a similar scale to Emacs, I would say. Since this *is* the current workflow, and changing to a dVCS (by itself) will not immediately increase the patch flow by anything like an order of magnitude, things will not get worse if this workflow is continued across the change in tools. > 2. "Lieutenant" / "subsystem percolation" > ------------------------------------------ > There is a "canonical" version of emacs that lives on savannah. (This is > always true so I'll stop mentioning it.) The project is split by > subsystem (and possibly is split further, resulting in a tree > structure), and for each a maintainer keeps a source tree with changes > to that given subsystem. When two subsystems need to be updated > simultaneously due to an interface change, the lieutenants coordinate > amongst themselves, pulling changes between each other. > > When a change is deemed ready to go to trunk (or to a parent node in the > tree), the upstream maintainer pulls these changes into her tree. Note > here that changes are only pulled, never pushed. > > Very often, subsystem maintainers "merge down" changes from trunk, so > that bugfixes/stable new features from other branches are continually > integrated. Everyone works hard to ensure that changes don't break > anything upstream. (cf. the ongoing VC-mode restructuring; under this > scheme those changes would not have been pushed to trunk until they were > complete and tested.) > > This approach scales VERY well (it's what linux-kernel uses, and their > code churn rate is *incredible*) but is probably wrong for emacs. 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. For Emacs in particular, at least two of the central maintainers (Richard for all of Emacs and Alan MacKenzie for CC Mode) would be potential bottlenecks because of their personal workflows. Also, several others of the plausible subsystem maintainers have expressed misgivings which might imply that they are not interested in functioning as pull-style gatekeepers. Another problem is that all core Emacs developers have areas of interest, but if a prerequisite subsystem for "their" area has a problem, they are used to going in and fixing it unilaterally. This will clash with the "turf rights" that the subsystem maintainers have. Sure, turf rights have been worked out in many cases, such as Gnus and CC Mode, and when conflicts occur, they work out amicably (I'm thinking of recent discussions about refactoring various libraries maintained by the Gnus project into other parts of Emacs when integrated into Emacs). But AIUI in the Linux kernel workflow, the subsystem maintainers have nearly complete hierarchical power over access to parent systems. It *could* work in Emacs, but it will be a change, and I predict it would be a wrenching one. This workflow should therefore be approached with extreme caution by the Emacs developers. > 3. Mailing list w/ gatekeeper(s) > --------------------------------- > This is how mercurial manages its own development. Proposed changes are > sent in patch form to a mailing list, which is dedicated to the > discussion and review of such patches. The central repository is > read-only except for a small set of integrators. When a change has been > reviewed + tested, an integration crew member pulls the patch from email > into the central tree. > > This is the approach I'd suggest for emacs (and it's the one we > instituted for the project I maintain at my workplace). The main > advantages: 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 only a small number of gatekeepers have push access to the public repo, it is also a major change in personal workflow for them. Possibly excepting Richard, who IIUC already functions as a sort of Workflow 2 gatekeeper -- except that he doesn't come close to trying to review all patches, even though he is the final authority. This workflow also *should* be viewed with extreme caution by the core developers.