Re: What a modern collaboration toolkit looks like

[Gregory Collins <greg@maptuit.com>]

Richard Stallman <rms@gnu.org> writes:

> It sounds like "git push" is the real analogue of CVS commit, and that
> this is the closest match-up between the concepts of git and the
> concepts of CVS:
>
>    	  CVS           GIT
> 	  save file  =  commit
> 	  commit     =  pull or push
>
> But I still don't understand what step actually alters the trunk that
> users will get by default from the public repository.  Does `push' do
> that?  If not `push', then what?

The discussion thusfar has been centred on the nuts and bolts of
distributed version control, and I think the point that's getting
overlooked is that decentralization allows you to arbitrarily redefine
the topology of how change flows through a project.

To make this more concrete, here are some commonly-used workflow models:

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?)


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.


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:

 - code gets reviewed by more eyes. Cf. the emacs-devel+emacs-commit
   lists; it's my observation that bad changes are often discussed +
   reviewed AFTER they've been committed to the trunk. How many
   questionable or marginal changes are slipping by, do you think?

 - VC tools streamline the process of sending + reviewing changes. I can
   type "hg email tip" from my working branch to send my last changeset
   to the list for discussion.

On the negative side, this approach becomes asymptotically less
efficient as the number of patches per day increases. However: the
beauty of distributed version control is that you can rework your
topology at will.

To get a flavour for how this process works from a cultural standpoint,
you can read the mercurial-devel mailing list archive at:

    http://selenic.com/pipermail/mercurial-devel/

Thanks,

Gregory Collins <greg@maptuit.com>