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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
