[Monotone-devel] Policy branch example scenarios

[Zack Weinberg]

I thought I'd write down all the scenarios I can think of where a VCS'
policy component becomes relevant.  Keep in mind that as long as all
the developers on a project are still on speaking terms, and nobody's
trying to bend the rules, social convention can handle really complex
ACLs and commit procedures; GCC gets on just fine with no technical
enforcement of its rather Byzantine commit rules.  Thus with one
exception these are all cases where civility no longer obtains (or
never obtained to begin with).

* Stay On Your Side Of The Sandbox

 This is a variant on the canonical 'developer X has only got
 permission to commit to branches A, B, and C / files 1, 2, and 3'
 example, except that developer X used to be trusted to commit
 everywhere, and is now angrily disputing the decision to restrict
 them to specified branches/files.  In a distributed system, X cannot
 be prevented from changing their local database to re-grant access
 to the entire thing; therefore, we have to worry about what happens
 when X tries to push revisions that are okay according to their
 database's trust set but not okay according to the "official"
 database's.  Wim's been arguing for these to be excluded at netsync
 time, so they never show up in the official database at all; I think
 you definitely want that policy for the trust rules themselves
 (assuming they are kept as versioned data instead of external
 settings per Ethan); otherwise X can cause trouble by forking the
 policy branch over and over again.  You probably want it for
 everything else too, as it does the best job of making the point
 that X doesn't get to flout the decision.  We still want merging
 from X's branches to be possible, but that's not a problem, since it
 would be someone else doing it, and thus their key signing the
 branch certs.

 (Tangentially, this is an argument for allowing *only* branch
 restrictions, not file restrictions, because branch restrictions are
 much less likely to be contentious - X can still do whatever they
 want to the *code* and can still show it to people with only
 marginal extra effort, and people can still decide to merge
 whichever pieces of X's code they like.  I think it's good for the
 system to discourage bad social practices as well as bad technical
 practices.)

 (This is the "Sven Luther and debian-installer" scenario I was
 talking about on IRC.)

* Upstream Has Lost Its Mind

 In this scenario, the 'core group' of developers of some project do
 something which everyone else doesn't like, and so everyone else
 packs up and starts a fork on a new server.  In the examples I can
 think of, the something-which-everyone-else-doesn't-like has to do
 with the licensing, therefore migrating patches back and forth is
 *not* desirable.  However, some individual developers may want to
 push patches from their local databases into both sides of the fork
 (presumably they're okay with both the licenses).  Monotone already
 makes it very easy to promote a database from 'my local copy' to
 'new netsync-host database'; with policy enforcement, you'd also
 have to hack it to make yourself the admin and exclude the old core
 group, is all.  Again, these are permissions you want to enforce at
 netsync time, 'cos you probably don't want revisions with
 undesirable licensing in your database at all.

 (This is like the XFree86/X.org split, or the more recent and less
 publicized cdrecord/cdrkit split.)

* I'm Taking My Marbles And Leaving (Fine, Then! I Never Liked You Anyway!)

 In this scenario, the fork is prompted by personality conflict
 between members of the core team, and there may continue to be
 substantial overlap in developer base; thus there _may_ be a desire
 to allow continued unrestricted propagation between the databases.
 Certainly people will want to merge patches back and forth.  It
 seems to me, though, that (monotone not having any special "trunk"
 distinguished from other branches) this too can be handled with
 branch-based netsync restrictions.

 This scenario is the first one where I think both sides of the fork
 might consider continuing to share the "official" database, _and_
 simultaneously might want control over trust on their side of the
 fence.  That's the condition where you genuinely need a forked
 policy branch.

 (Canonical example here is probably the NetBSD/OpenBSD split. I
 heard some years ago that the various BSDs were considering merging
 their CVS repositories, at least for "boring" things like /bin/ls,
 but I have no idea what, if anything, came of it.)

* Velvet Divorce

 Even less dissonant, this is the EGCS scenario, where the split does
 not involve a personality conflict, just an irreconcilable
 disagreement over project policy; there may be an express or
 implicit desire to merge the two sides back together in the long run
 (as did in fact happen with EGCS).

 As long as both sides of the split are amenable to the _experiment_
 (while perhaps disagreeing on their expectations for the result)
 maintaining both sides in the same database makes a whole lot of
 sense.  The divergence here is, after all, not much more than what
 you see in a normal development branch.  However, in this scenario
 it's also quite likely that both sides want to maintain trust
 independently.  The EGCS split was largely over liberalizing the
 policy for granting commit rights (it's still quite conservative as
 these things go, but it used to be that you had to be invited and
 know the secret handshake before anyone would even tell you where
 the CVS repo was hosted).

* You Damn Kids, Get Off My Lawn

 I've never personally witnessed this one, but Ethan Blanton on IRC
 was most concerned about it.  This is the situation where someone
 who *hasn't* been involved in the project decides that they can do a
 better job and forks it.  Monotone makes this rather easier than it
 is with, say, SVN, and that's a good thing.  The trouble here is
 that -- assuming the existing development team is active and not
 suffering from any of the above dysfunctions -- such forks tend not
 to survive long, because they don't have the mindshare or the
 manpower to keep them going.  It is not desirable for people
 following the main track of development to be bothered by such
 forks.  However, this is not a problem as long as the people doing
 the forks don't have admin privileges on the official database; they
 can fork, sure, but only by setting up their own netsync server, and
 everyone who still has confidence in the primary dev team can just
 ignore it.

* Op Wars

 Again, I've never seen this happen in real life with a free software
 project.  I *have* seen it happen on Wikipedia, though, and any of
 my first three examples could plausibly look like this while the
 split was happening.  Basically, this is the scenario Nathaniel laid
 out in one of his original messages, where Mallory and Nogoodnik
 simultaneously try to revoke each other's admin rights.

 I'd argue that there is no computable Right Thing that monotone
 should do in this scenario. I use the word 'computable'
 deliberately; the Right Thing is going to rest on squishy human
 factors.  However, working out the squishy human factors and
 determining what the right trust set is will take time, and we don't
 want to leave the database unusable while it's being sorted.  Nor do
 we want to make it impossible to get rid of troublemakers quickly --
 even troublemakers with admin rights.

* Oscillating Cspec Of Doom

 This is my one scenario which has nothing to do with social issues;
 it's a potential undesirable consequence just of keeping management
 data for the VCS as data managed by the VCS.  Basically, you want to
 make sure that it is impossible for a policy revision to take itself
 out of the set of trusted policies.  Here's a very simple scenario
 where this could be a problem: Alice (an administrator) resigns from
 a project, and does so not by asking some other administrator to
 revoke her access, but by doing so herself; so you have a policy
 revision that denies Alice authority, *signed by Alice* -- so it
 doesn't trust itself.  Clearly such a policy is invalid, so the
 system ignores it and goes back to the previous policy -- which
 *does* trust Alice, at which point the new policy is a candidate
 again.  The consequences would depend on details of implementation;
 the worst-case scenario is probably that Alice is included in the
 trust group half of the time and excluded the other half, causing
 the set of trusted certs to oscillate likewise, and in turn that
 causes file contents to oscillate.  (You probably need several more
 bugs on top of the original for it to get that far.)

 (This scenario borrowed from a horror story I was told in my old job
 while doing on-site work with a company that used ClearCase, whose
 "cspec"s are rather like default branch options, except much more
 complicated -- and being oft-lengthy text files, get stored inside
 ClearCase themselves, rendering it a relevant question which version
 of the cspec is visible given the cspec itself...)

... So how do I think it should work?  See the next message; this one
is quite long enough.

zw