From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Mon, 31 Dec 2007 13:11:29 +0000 Message-ID: <20071231131129.GA2737@muc.de> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199106184 3229 80.91.229.12 (31 Dec 2007 13:03:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2007 13:03:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 31 14:03:17 2007 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 1J9KIV-0001lz-Pf for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2007 14:03:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9KIA-0005XI-2X for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2007 08:02:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9KI7-0005Wq-4D for emacs-devel@gnu.org; Mon, 31 Dec 2007 08:02:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9KI6-0005WR-77 for emacs-devel@gnu.org; Mon, 31 Dec 2007 08:02:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9KI6-0005WO-3X for emacs-devel@gnu.org; Mon, 31 Dec 2007 08:02:50 -0500 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J9KI5-00046Y-D5 for emacs-devel@gnu.org; Mon, 31 Dec 2007 08:02:49 -0500 Original-Received: (qmail 82862 invoked by uid 3782); 31 Dec 2007 13:02:44 -0000 Original-Received: from acm.muc.de (p57AF476D.dip.t-dialin.net [87.175.71.109]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 31 Dec 2007 14:02:42 +0100 Original-Received: (qmail 3767 invoked by uid 1000); 31 Dec 2007 13:11:29 -0000 Content-Disposition: inline In-Reply-To: <20071230122217.3CA84830B9A@snark.thyrsus.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:85729 Archived-At: Happy New Year, Eric and Emacs! On Sun, Dec 30, 2007 at 07:22:17AM -0500, Eric S. Raymond wrote: > ...., I think it will be useful if I start by giving everybody a clear > idea of the potential benefits of changing our practices. > I'm going to describe the collaboration toolkit on another project > where I happen to be a senior dev, called Battle For Wesnoth. You can > find the project at . > This is a typical modern open-source project. Emacs is an atypical, very old, piece of free software. Wesnoth seems to be about 5 years old. (I haven't found the repository online.) This has some bearing on the differences in development processes. > .... Here are the collaborative tools we use every day: > * Source control with Subversion > * A bug tracker > * A very active IRC channel used for routine dev chatter > * A dev mailing list, used mostly for white papers and long proposals > * Web forums where a large user community hangs out > * Subversion commits are echoed to IRC in real time by a monitor bot > * Subversion commits that reference a bug append a comment to the tracker > * A bot on IRC that you can query with a bug number and get a tracker URL. > Here are some of the ways my workflow on Wesnoth differs from my > workflow on Emacs: > 1. When I do a commit of changes to several files, the entire changeset > is saved as a unit with a single change comment attached to it. I would appreciate having this in Emacs. > a) That change can be referenced, through its Subversion revision ID. > (So, for example, "Hey boucman, your r22615 broke linger mode!") Hopefully, people are considerate enough not to do this too often; continually having to look somewhere else to get context is not nice. > b) That change can be backed out as a unit. That's fine if nearly all changes are independent. In Emacs, I think, this is not the case. The codebase is extremely old, and clean structuring has in many cases been lost. (But, hey, for >20 y.o. code, it's not bad). Such easy backing out could lead to problems. [ .... ] > 2. My commit is also echoed to the IRC channel, where there are almost > never fewer than three or four devs hanging out as they hack, chatting > in real time. Review tends to happen instantly. What about fixes that are too big for instant review? Emacs has lots of bugs (and often fixes ;-) that are barely tractable, so that the slower pace of email seems a better fit. [ .... ] > The effect of all these tools is more than the sum of its parts. > One huge one is simply that devs can choose to spend time picking bugs > off the tracker and nailing them, with basically zero process friction. > Another is that we routinely hash out serious design and coding issues > in real time, because everyone on the chat channel can share hyperlinks > to the codebase, the commit history, the bug tracker, and posts > on the user forums. I've no experience of IIRC. But doesn't this way of working mean continually dancing from one thing to another? I don't do that very well. The "hyperlinks" bit sounds like you have to look at 3 or 4 things simultaneously to be able to synthesise a context. How does this working style work for difficult problems? > Yet a third is that when we decide to do it, we can converge on a > releasable state with almost absurd ease. Like, Ivanovic (our release > manager) will announce "Point release scheduled this coming Wednesday" > and everyone will pretty much flip into bug-stomping mode. The tracker > bug list tends to shrink dramatically when this happens -- not only do > we get prepared for release but *we know we've done so*. Eric, how well do you think this could work at all for Emacs? > More generally, development happens *fast*. I don't have to wait weeks > to find out whether other devs think of an idea. Commonly I know > within minutes. On emacs-devel, this takes hours, not weeks. At any given time, most Emacs developers are either asleep or doing other things (like earning their living). Doesn't this quick-fire style end up excluding lots of hackers from participation? > The Wesnoth devs are good but not exceptionally so, and we're weighed > down by a crappy implementation language (C++). Yuck!! > Nevertheless our productivity, in terms of goals achieved per hour of > work, is quite high. That's because our collaboration tools support > everything we do without imposing noticeable process friction. This > makes us dramatically more effective as individuals and as a group than > we could possibly be without them. Might it also be because your code base is still young, clean and flexible? > Lessons for the Emacs project? Hell, yes. But I'm not going to write > that rant until y'all have had a little time to absorb this description > of how things can be. I'll look forward to that! We'd all welcome a process for releasing every few months rather than twice a decade. -- Alan Mackenzie (Nuremberg, Germany).