[Cryptech Core] git repository usage patterns and access control

[Rob Austein]

I'm pretty sure we need to institute code review.  Gerrit is certainly
one way to do that, and does indeed appear to automate a lot of stuff.

I have minor concerns with how to secure something like Gerrit
properly, but I think I know how to address most of them.

I would be a lot more uncomfortable with putting a huge piece of code
like Gerrit on our critical path were we not already using signed
commits (which, as I recall, was Peter's recommendation in the first
place, so he may be ahead of me here too).

Just to confirm: Gerrit will work with signed commits?  Gerrit itself
won't ever try to generate commits that would need to be signed?  From
spot reading of Gerrit's documentation, I think the answers are "yes"
and "no", respectively, ie, it'd be OK.

The real questions for the group, though, are whether Gerrit's model
of code review is the workflow we want, and whether it's the right
weight of tool for this project.

I can outline the code review process we used at ISC if there's
interest.  Summary: all new code was developed in branches, which had
to be reviewed before being merged to (CVS, sigh) HEAD; reviews were
tracked in the ticket system (RT) via a somewhat ritualized process.
Worked well enough as far as getting the code reviewed goes (opinions
vary on how much that helped code quality -- code review is  necessary
but not a cure-all).

Even with Gerrit we'd need to document our process; one of the main
advantages Gerrit appears to have is that it automates enough of the
process that the number of voodoo steps a committer would have to
follow would likely be smaller.

While we're on the subject, if we go with something like Gerrit, do we
want to throw Jenkins into the mix?  Continuous integration tests on
FPGA might be an entertaining project for somebody....