Re: [Monotone-devel] Re: GCC and Monotone

[graydon hoare]

Zack Weinberg wrote:

> I realize this, but please understand that it's going to be much
> easier for us GCC folks (or any large project for that matter) to
> migrate to monotone if we don't have to change our development process
> drastically at the same time.

I understand this, yeah. I just wanted to make sure you understood me, 
too: there's no "natural" central-authority facility in monotone for 
maintaining that part of your development process, so you have to fake one.

> I think this can be modeled by publishing
> a list of public keys whose approval certs are to be taken seriously.

I think the net result will be people publishing a lua function on a 
project web page -- or sharing it around through email -- saying "this 
is the trust function we use".

it sounds good in theory to let each client define their own trust 
policy, but in reality a tight-nit group of people collaborating have 
such transitive-trust issues (not to mention the desire to merge the 
same head set) that they probably need to be using more-or-less the same 
trust function, at any given time.

subscribers who are just following them, on the other hand, can pick 
whatever function they like.

> The issue is complicated by the "obvious fix" rule which says people
> are allowed to check in sufficiently obvious fixes with no approval.

well, your current "security system" for these people is social 
pressure, which might well be enough, so you'd reproduce it the same 
way: chastise them if they commit and approve of something too big, 
otherwise trust them.

if you actually want to isolate the secondary group from the main group, 
you need to put a human brain in the way. say assign a rotating member 
of your core group the duty of reviewing and certifying all obvious 
fixes. you could make this a sweet deal by exempting the 
obvious-fix-reviewer from all other "serious" reviewing duties while 
they're so assigned :)

> Another issue is merges. [...] By the time
> someone gets around to approving it, things on HEAD may be very
> different; we need to have a range of options available when issuing
> that approval cert.   The basic action, I think, is "Approve this,
> generate an automatic merge packet against HEAD, then let me look at
> the result."  I then get to say "yes, good merge" or "no, let me fix
> that" or "no, tell the original author to resolve the conflicts."  The
> latter two leave the botched merge as tip of an evanescent branch, so
> the work is not lost.  Does that make sense?

makes sense, but I think this is more complex than necessary.

tell bob to label his changes as belonging to the branch 
org.gnu.gcc.contrib.bob, and tell him it's his problem to keep his 
changes up to date by regularly propagating from org.gnu.gcc.

if you see something you like in org.gnu.gcc.contrib.bob, approve of it, 
and try propagating his branch back to org.gnu.gcc. if it fails, it 
means his changes didn't merge. leave it. he'll figure out something's 
wrong since you approved but didn't propagate his change. if it was ok, 
take a look at the results of the propagate. maybe fix them up, maybe 
post them, maybe throw them away, leaving bob's change back in his own 
branch.

(modulo the merge-into-dir UI improvements, which will hopefully make 
the "look at it / fix it up / throw it away" part a little nicer)

-graydon