Jesse Becker <becker...@mail.nih.gov> writes:
> On Fri, Jan 28, 2011 at 01:51:54PM -0500, Eystein M?l?y Stenberg wrote:
>>Interesting. Are any of you using commit hooks for peer review? I.e.
>>"don't allow a change to go to repository unless it has been approved by
>>5 people"?
>
> I thought about this a little bit, but decided that simply reviewing the
> commits by eamil after the fact is a lot simpler than trying to do it
> before the commit.
>
> You're basically suggesting a quorum setup. How do you account for
> people going on vacation/out sick/at meetings, etc? What about
> emergency fixes (not that you should ever need those...).
Yeah, that all sounds pretty dodgy.
This seems more likely to work better with one of the distributed SCMs
(git, bzr, mercurial, ...), where responsibility for commits is a bit
more distributed.
- You can commit anything you like on your own workstation... That
gives you a commit...
- Then, the commit needs to get promoted to the "official repository,"
which requires jumping through some set of hoops, such as:
- Quorum signoff, where a set of people have to sign off to get it
accepted.
- Emergency signoff, involving a different, likely smaller set of
people, who get cranky if it wasn't important enough to warrant
interrupting them.
- Nifty idea is to have automated signoff, where you submit the commit
to some kind of test server ("continuous integration" is the common
term) where it gets applied, and a regression test is run.
It would be reasonable for this to represent some portion of the
"quorum" described above.
>>Perhaps using multiple repositories would help?
>
> You could do multiple branches of one repository, assuming you impose
> some sort of access control on commits to the different branches. For
> example, given one repository "repo", with two branches:
>
> repo:/cf3/dev
> repo:/cf3/prod
>
> Anyone can commit to /cf3/dev, but not /cf3/prod.
>
> The only way for code to make it into /cf3/prod is via a 'merge' command,
> driven by an external database and scripts that track commits to the
> dev branch, and merges once there are certain number of votes. This
> could get complicated quickly, but I think could be possible. You don't
> want to have to vote on every individual commit at a time, and some
> patches will "depend" on other patches. That could get ugly...
So there are "weak commits," going to dev branch, which get promoted to
the 'prod branch.'
The Distributed SCM approach feels more natural to me here, and it might
be worth migrating to another SCM for this.
--
let name="cbbrowne" and tld="afilias.info" in name ^ "@" ^ tld;;
Christopher Browne
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
