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

[graydon hoare]

Tom Lord <address@hidden> writes:

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

whatever you like. I'm not trying to force a policy on anyone, merely
provide a mechanism to express and evaluate your chosen policy.

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

I want to explicitly "link" trust to each update operation (and merge)
because it already is, implicitly. when I sit down to work each day,
my VC system is responsible for selecting the version of software I
will be basing my work on. this is true with any VC system, and it's a
lot of responsibility to trust it with. if it chooses poorly, my day
is wasted diagnosing other people's bugs.

I would like a way to teach my VC system which criteria I want my
daily updates and merges to pass. if that criteria means "friends from
usenix", I should be able to express that. if it means something else
-- results of autotests, review, copyright assignment, whatever -- I
should be able to express that too.

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

if that's your policy, you ought to be able to express it. I accept
code from some people I don't know (after reading it), and I reject
code from some people I've gone camping and gotten drunk with (because
it fails a test). the policy choice should be mine.

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

I'm only thinking that checking a set of signatures from various
parties is an approximation of some trust policy you have, whatever it
may be. you keep implying that monotone forces a trust policy on
users. it does not.

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

I disagree. I think arch takes an over-engineered approach to these
issues, achieves less than it should, and does so inefficiently. but I
doubt we will resolve this disagreement any better than we have
resolved those already on the table. perhaps we should let the thread
die.

-graydon