Re: What a modern collaboration toolkit looks like

["Stephen J. Turnbull" <stephen@xemacs.org>]

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.