From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Mon, 31 Dec 2007 10:25:09 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20071231152509.GC8641@thyrsus.com> References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231131129.GA2737@muc.de> Reply-To: esr@thyrsus.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199114734 26649 80.91.229.12 (31 Dec 2007 15:25:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2007 15:25:34 +0000 (UTC) Cc: "Eric S. Raymond" , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 31 16:25:48 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 1J9MWP-0003MF-Kw for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2007 16:25:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9MW3-00040U-VL for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2007 10:25:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J9MVy-0003ug-B3 for emacs-devel@gnu.org; Mon, 31 Dec 2007 10:25:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J9MVx-0003sY-Bj for emacs-devel@gnu.org; Mon, 31 Dec 2007 10:25:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J9MVx-0003sL-8K for emacs-devel@gnu.org; Mon, 31 Dec 2007 10:25:17 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5] helo=golux.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J9MVw-0001HV-RB for emacs-devel@gnu.org; Mon, 31 Dec 2007 10:25:17 -0500 Original-Received: by golux.thyrsus.com (Postfix, from userid 23) id 9669DCF80C1; Mon, 31 Dec 2007 10:25:09 -0500 (EST) Content-Disposition: inline In-Reply-To: <20071231131129.GA2737@muc.de> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:85741 Archived-At: Alan Mackenzie : > 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. Indeed. It means we have a lot of history and bad habits to unburden ourselves of, and that's a problem Wesnoth does not have as acutely. (It dates from 2003.) > > 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. In fact that particular situation is rare. My point was that Wesnoth's communications tools help us correct such problems quickly. What a fighter pilot would call our "OODA loop" is very fast. > > 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. It's actually very useful even when changes are intertangled. For one thing, it makes isolating regressions via a bisection search practical. While this is theoretically possible under CVS, there is just enough friction to make it something people seldom or never actually do. > Such easy backing out could lead to problems. I find that the problems of easy backout are far outweighed by its benefits. As a recent example: my lieutenant on one of my other projects (GPSD) committed a change that broke our regression tests. It was a day and a half and about a dozen commits later when I noticed this. It matters that I was *immediately* able to back out both the bad commits with high confidence that I was not leaving the code in an inconsistent state. (And rap him on the knuckles, but that was a social act and not a technical one.) > > 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. IRC functions as a kind of triage on such changes. If we can't resolve a problem in real time, we fall back to the mailing list. This happens much less often than I myself would have expected before I became used to this style. I'll admit, it did take me some adjustment to get used to. The Wesnoth devs are mostly kids who have grown up in a post-MTV world, used to constant multitasking. I just turned 50. When I first contemplated getting involved, about nine months ago now, I had to wrestle with some fear that (a) I would be distracted and losing focus all the time, and (b) worse, I might discover that I was simply too old and lacked the mental agility to keep up. The second, especially, would have been crushing. I had to screw up my courage to try doing things their way lest I discover myself to be inadequate. In fact, both fears proved groundless. Nowadays I routinely have an IRC client open in five tabs to three different projects, and it all just becomes part of my flow. I think it matters a lot that IRC chat is silent -- I absolutely can't imagine imagine maintaining concentration while multiplexing that many voice channels. And far from finding I can't keep up, I've discovered that I like the stimulation. I grok how the kids feel about this, because mailing-list-only projects have started to seem slow and boring to me, too. > 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. See above. I myself was afraid I wouldn't be able to handle this. But I adapted, and now I feel really liberated by having done so. > 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? Same way it does for easy ones. The difference is that with older, slower workflows we had to absorb all those bits of context more or less serially and buffer them in our heads for relatively long periods of time. I don't have to do that as much now -- it's more about keeping track of where the context is and quickly swapping in the parts I need at any given time. > > 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? I'm going to stop waving my hands and run some numbers. According to sloccount, the C core of Emacs is just about twice the size of Wesnoth's C++. Assuming the usual quadratic rise in bug density with LOC, the equivalent release tempo would be three months. But I think that's an overestimate. Our devs are more capable, and a fair amount of the Emacs core is either effectively dead (like, say, the VMS support) or so stable that it never needs to be touched. Then there's the C vs. C++ difference. All in all, I think six weeks is a reasonable guess for where we'd end up. "But..." I hear you say "you're ignoring the Lisp!". Yes, I am -- and that's because one thing rather clear from the Changelogs and NEWS files is that the Lisp code is not where the long-term release blockers tend to pop up. > > 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? It doesn't seem to work that way in practice. Or, at least, I don't hear hackers bitching about not being involved in decisions. What the core devs (including me) seem to do is keep one eye on the project IRC channel more or less constantly while doing those other things. > > The Wesnoth devs are good but not exceptionally so, and we're weighed > > down by a crappy implementation language (C++). > > Yuck!! Indeed. I've had to become competent at it. This has been painful. > > 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? It's an appealing theory, but...no. The Wesnoth code is not at all clean internally, and the Wesnoth devs themselves often bitch about its rigidity. There are two reasons for this. One is C++; enough said. The other is that the Wesnoth devs are, on average, somewhat less capable and a lot less experienced than Emacs's have been -- and their most serious weakness tends to be a very limited understanding of design for maintainability. The result, unfortunately, is that while the Wesnoth code is much younger than of Emacs, it has already achieved a comparable cruft level :-(. > > 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. Yeah. That would be good. My worst-case estimate, with modern tools, would be a three-to-four month release cycle. -- Eric S. Raymond