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

[Tom Tromey]

Tom> Incorporation of cryptographic-signature based "acceptance criteria"
Tom> into security-sensative processes accomplishes nothing more than to
Tom> raise the pay-off to bad guys for acquiring the ability to spoof or
Tom> abuse a signature.  Decentralizing trust in that manner accomplishes
Tom> nothing more than to raise the number of opportunities to steal
Tom> private keys, or worse, to play the "patient ringer" game of acquiring
Tom> undeserved trust by establishing a track record of apparently positive
Tom> participation in public projects.

I don't think monotone offers significantly more opportunities here
than does the currently prevalent cvs+ssh.

With cvs, we already have the problem of identifying a real person
with his ssh key.

Anybody can already fork any existing code and make their own release.

Any maintainer with write access is already potential target for
espionage of various sorts.  Likewise, any maintainer could switch to
the dark side at any moment and wreak havoc.

Tom> An alternative to an "acceptance criteria" based on trusted signatures
Tom> is the scientific method: repeatable results from independent code
Tom> reviews and independent testing.

I don't see how monotone excludes this method.  You can easily have
code review -- see the gcj example in my earlier message.  In fact, it
seems to me you could implement apache-style voting pretty directly in
monotone: you could have a robot that signs versions based on the
number of votes (also expressed as signatures) it gets from
"committers"; the robot would "anti-sign" vetoed versions.  (The
"real" version of the code would come from trusting the robot, not any
individual committer.)

Independent testing is also easy, because there's a simple mechanism
for testers to express "this version is ok" -- each test box would
sign versions it tests according to the results, and developers can
choose both the testers to trust and the criteria according to which
they want to update.

This fits in nicely with gcc development.  For one thing, it would
make the gcc test results mailing list actually useful, in the sense
that you could listen to it and collect information about what is
working.  Then you wouldn't need to worry about whether "cvs update"
on Monday morning is going to screw you, since you could always update
to "known working" or "very latest" depending on what you're doing.

Tom> Why in the world is this a new problem which requires a
Tom> version-control-specific solution?  Surely the various parts of this
Tom> company face a huge and open-ended number of needs for reliable
Tom> communication between parts.  Surely any one part of the company must
Tom> communicate reliably to other parts countless types of information,
Tom> constantly.   Why, then, a version-control-specific solution?

I don't think the problems here require this sort of solution.  There
are many potential solutions out there.  However, I find monotone's
approach elegant.

I deleted a lot of stuff about noisy communication between the QA
department and the rest of the company, and all that.  I think that
was related to an example that went awry.

Tom