Re: [Monotone-devel] newcomer (rude, but hopefully not to rude) questions

[Tom Lord]

    > From: graydon hoare <address@hidden>

    > so, if I read correctly your suggested solutions to having a machine
    > evaluate the trustworthyness of a version in a VC system boil down to
    > one of:

    >   - meet the author in person and exchange checksums, using your latent 
    >     human social-trust evaluation ability

    >   - run the testsuite on every possible failure you're concerned about

    > I agree that these would be stronger, but argue that both are
    > prohibitively expensive to perform on each update operation.


I have the sense that you are trying to make those two `-' points seem
obviously, patently, absurd -- when to me, they seem only to be
somewhat exaggerated and slightly distorted.

So, no, you do not seem to read me correctly.

What constitutes "the trustworthyness of a version in a VC system"?

Partly, to be sure, there are questions about the trustworthyness of
communications.  That's a fairly minor and long-ago solved problem.
Monotone's hacks are a new solution that has some applications -- I'd
like to see the ideas that underlie it developed further.
Nevertheless, it's a solved problem even absent Monotone's hacks.

Partly, to be sure, testing and code review are big components of
evaluating trustworthyness of code.   I don't know why you want to
link this to "on each update operation" -- that's silly.  But those
are certainly important components to insert on the path to widespread
deployment and which, Raymond's afforisms aside, we generally don't do
in the free software world in an effective way.   We're sitting ducks,
in that regard.

Meeting people:  that's what I wanted most to talk about.

Meeting people is more than just a question of "look some guy in the
eyes as he hands you a piece of paper with a checksum on it."  Much,
much more.

The checksum is relatively unimportant.   That's just double-checking
the communications channel.   The real question, since our software
has grown to such non-human scales of complexity -- is who the hell
are you accepting that checksum from?

Meet the guy, yes.   Get drunk with him.   Meet his parents.   Meet
his spouse and kids.  Spend a week after the conference at his house
and let him do the same.  Go camping with him.   Go to wine country.
Get to know that guy, plus 10 others that also know him.  The graph of
such relationships among us free software hackers should be quite,
quite tangled -- think to the point of opaqueness with links between
nodes.   Ah... the sorrowful "burdens" of our duty.

Building that graph is, or at least used to be, a very large part of
the function of the usenix backbone.  A large part of the social
network that surrounded the conferences.

The non-Internet-mediated social network of hackers is _supposed_ to
be the most important component in achieving and maintaining the
integrity of our shared source.

I'm sickened by things like web sites that try to reduce that social
network to, for example, voting on a blog about who's a "journyman"
and who a "master".  Such reductionism entirely misses the point.
It's decadent beyond any hint of respectability.

So when you tell me you're going to give me a technology to make
digital signatures part of the acceptance criteria of source code -- I
really start to wonder what you're thinking.

This corpus of source code we call "free software" is _far_ more
complex than anything that could be called a human scale.  You're damn
right if you say that the wet-space human network is of paramount
importance.

Expensive?  Sure... that's a large part of why we're supposed to be
well paid and have hefty per diems.   And if some authority starts
telling you "well, the economy is too tight for that" -- that's a time
to put your foot down and your career on the line.   Professional
responsibility requires nothing less.   Quit if you have to.



"/* You are not expected to understand this. */" -- but if you do,
that's good.
-t


p.s.: In many regards, arch has nailed the design space of revision
control systems.   We're _way_ on top of things like branching, and
merging, and cataloging.   When you talk about Monotone's features and
plans in these areas -- they come across to me as a small subset of
what arch can do, mixed with some confusion about where signatures and
checksums fit in.    If the goal is to make a really great revision
control system, especially if it's to make a system for the "FOSS"
world, well, you know where to find the gnu-arch-users mailing list.