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

[Zack Weinberg]

graydon hoare <address@hidden> writes:
...
> 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.

Okay.  I think we're on the same page here, this makes sense.

>> 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 :)

It's not clear to me that I can use the social-pressure system and at
the same time get the nice "just send mail to approve a patch"
feature.  If the reviewee could approve their own patch, ... oh wait;
they would be on their honor to not do that if they weren't allowed.
(Which is basically the same as it is now.)  That works.

> 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)

This sounds good.

One last issue: denial-of-service.  If we have the official depot
take patches by email from anyone (which I like, since it makes it
much harder to drop patches on the floor) then what's to stop someone
sending either a gargantuan patch, or a long series of small patches,
and filling up the disk?

zw