Re: What a modern collaboration toolkit looks like

[Gregory Collins <greg@maptuit.com>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> 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.

Hi Stephen,

My remarks weren't meant to urge any immediate course of action, but
rather to attempt to broaden the discussion to include possible answers
to the question "why would you bother switching?" A discussion that
centres on "how do these CVS concepts map to a distributed context?"
will tend to obscure the most compelling arguments in favour.

Clearly nothing is going to happen in a rush here (nor should it),
because even if it's decided that the horse needs a cart, it's going to
take months to decide

  a) what kind of cart
  b) two wheels or four?
  c) metal, wood, or composite?
  d) "what's wrong with saddlebags, anyways?"
  e) "You guys are soft, I walk everywhere, barefoot"
  f) "I live in Nunavut, so it's VERY IMPORTANT that the cart have
     optional skis"

  ... ad infinitum ...


>  > 2. "Lieutenant" / "subsystem percolation"
>  > ------------------------------------------
>  > ...
>
> 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.

Agreed.

>  > 3. Mailing list w/ gatekeeper(s)
>  > ---------------------------------
>  > ...
>
> 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 it's a choice between "60 minutes per patch" and "little or no code
review at all", I think everyone will agree that the review wouldn't
happen. "Formality of code review" is a continuum, however, and it's my
experience that you can stop a lot of bugs without pulling out the
magnifying glass and tweezers.

You may be right that the extreme hairiness of emacs code may invalidate
that assumption. I'd argue regardless that the more eyeballs you can get
on incoming patches, the better.

I'd also argue that despite some impetuous claims to the contrary, the
reports of emacs' imminent demise are greatly exaggerated.

G.