[Monotone-devel] Re: [RFC] versioned policy -- introduction

[Graydon Hoare]

Bruce Stephens wrote:

> More than that: that's an important feature, not a bug.  I shouldn't
> be prevented from committing to a tree just because its owners haven't
> (currently) allowed me to.
>
> So is there something you aren't describing, to do with how all this
> gets enforced?

Enforcement is indeed a key issue, as you and others have noticed. The 
thing to remember is that even if we use terms like "ACL", there's 
really no single resource to control access to. There's a cloud of 
resources, each with its own physical owner.

The point of this work is not to change the trust model of monotone. You 
still have final say on what happens with your computer, bob still has 
final say on what happens with his computer.

The point is to make it easier to do three things:

  - Write trust policies (both update-trust and netsync-trust)

  - Share trust policies across a workgroup automatically

  - Learn about the policy in force across a workgroup such that
    you don't personally commit policy-violating work that will
    only be rejected by everyone else.

IOW there will always be a "commit --force" command, because it's both 
immoral and technical nonsense (outside of DRM+PKI fantasy-world) to try 
to prevent someone from committing a file to a disk they own using a 
free software tool. You could always just comment out the line of code 
that enforces (or "suggests") policy on commit, after all!

There will also always be the possibility of pulling some revs and 
applying "different policy" to them than the original authors were 
operating on. So there's no change to your right to make forks without 
telling your upstream; again it's sort of technical nonsense to leave 
such a feature out. But such a right doesn't make shared policy useless: 
if you break policy X, everyone who has their monotone set to "follow 
policy X" will stop dealing with you. Just like now, only with more 
automation for sharing.

(I'm making bold statements-of-fact here about what "will be", because I 
think everyone who's bothered discussing this work up until now has 
agreed on this stance; if I'm misrepresenting your views of course speak up)

-graydon