[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: graydon hoare
Subject: Re: [Monotone-devel] Re: GCC and Monotone
Date: Tue, 02 Dec 2003 17:42:59 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031115 Thunderbird/0.3

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)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]