[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What a modern collaboration toolkit looks like
From: |
Alan Mackenzie |
Subject: |
Re: What a modern collaboration toolkit looks like |
Date: |
Mon, 31 Dec 2007 13:11:29 +0000 |
User-agent: |
Mutt/1.5.9i |
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 <http://www.wesnoth.org/>.
> 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).
- Re: What a modern collaboration toolkit looks like, (continued)
- Re: What a modern collaboration toolkit looks like, Nick Roberts, 2007/12/31
- Re: What a modern collaboration toolkit looks like, Eric S. Raymond, 2007/12/31
- Re: What a modern collaboration toolkit looks like, Eli Zaretskii, 2007/12/31
- Re: What a modern collaboration toolkit looks like, Miles Bader, 2007/12/31
- Re: What a modern collaboration toolkit looks like, Eric S. Raymond, 2007/12/31
- Re: What a modern collaboration toolkit looks like, Miles Bader, 2007/12/31
- Re: What a modern collaboration toolkit looks like, Eric S. Raymond, 2007/12/31
Re: What a modern collaboration toolkit looks like,
Alan Mackenzie <=
Re: What a modern collaboration toolkit looks like, Eric S. Raymond, 2007/12/31
Re: What a modern collaboration toolkit looks like, Nick Roberts, 2007/12/31