Re: What a modern collaboration toolkit looks like

[Thien-Thi Nguyen <ttn@gnuvola.org>]

() Glenn Morris <rgm@gnu.org>
() Sun, 20 Jan 2008 22:16:05 -0500

   Is anyone trying to tell me, that switching to some hip new
   version control system is going to make people start applying
   the patches that currently sit around in this mailing list for
   weeks?

Although i haven't in the past, i would be willing to tell you
that, and will take time to explain why, now:

Emacs hacking requires thought to "DTRT", which is inhibiting to
me because experience leads me to ponder (mostly enjoyably, but
more germainely, always lengthily) on the history of the context
of that acronym as uttered by a specific person, to avoid getting
burned by misunderstanding.  When rms sez "DTRT", i work hard to
disambiguate its meaning from when jrhacker sez "DTRT".  Perhaps
others find it easier; i cannot speak for others.

A distributed version control system (my bias is towards git at
the moment) separates DTRT_process from DTRT_code up to the time
of publishing the change.  The effect is that i can parallelize my
pondering to some (Amdahl-limited ;--) extent, and thus check in
things faster.

Now let's turn from commit 0 in a series, to commit N.  Why is
there a commit N?  Because commit 0 was problematic in some way,
even though supreme effort was (presumably) expended to DTRT.
i.e, commit 0 did NOT DTRT; i make mistakes, i misunderstand.

A distributed version control system would mitigate this by
letting me do commit 0 locally, iterating N times until my
practice matches what is considered to be TRT.  This is basically
a restatement of the parallelized pondering paragraph above, w/
s/understanding/practice/g.

"But", you may be thinking, "what does that have to do w/ patches
that have been sitting around for weeks?"

Well, i have write privs and i am happy to check in code that DTRT
from those that do not have write privs.  But how do i know that
code DTRT?  How do i know its author has iterated enough so that
the understanding/practice reflected therein has the quality of
commit N and not quality of commit 0?

One answer to these questions starts w/ "It's none of your
business; why do you care?; your part is merely secretarial."  To
which i can only say: sorry, i do care, and will ignore arguments
in that vein.

Another answer is: "Learn the code; use the opportunity of its
passing through your brain to expand your expertise -- in that way
you will recognize if it DTRT."  To which i say: agreed mostly,
but not fully.  I can expand my understanding of such code, per
se, but w/o access to its history, the understanding is illusory
and incomplete.  There is a chance that i have merely stumbled
upon a superficial outcropping of deeper (more interesting)
issues, that my grokking is mere luck, and most dangerously, that
the overlapped (between myself and the code's author) grokking is
transitory.  "Looks good because of X", thinks ttn.  "*IS* good
because of Y", thinks its author.  Patch applied.  Fast-forward
two months; ttn hacks on the code to support X better, breaking Y.
Lose.

IMHO expanding my expertise is best done by building on the
expertise of others.  A distributed version control system
combined w/ people's disinhibition of exposing their mistakes
allows me to more quickly grok the thought that went into the
presented patch as well as the code it changes, align my thoughts
w/ it, iterate w/ the author as necessary to achieve quality of
commit N, and apply it.

In the end, my spewing here might seem like an indictment of DTRT.
Perhaps.  But i tend to think otherwise: i think "DTRT" ethos
needs to grow up and leave the nest.  This involves two things:
supporting a phase separation of D and TRT, and expansion of TRT
to not only accept mistakes, but to actively support archeological
non-punitive reflection on the actions that surround them.

thi