[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Policy branch example scenarios
From: |
Zack Weinberg |
Subject: |
[Monotone-devel] Policy branch example scenarios |
Date: |
Sun, 10 Sep 2006 23:48:17 -0700 |
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] Policy branch example scenarios,
Zack Weinberg <=