Gerrit: Google-style code review meets git

The centralized focus has occurred precisely because of the corporate
framework that exists around the original user group. Google built Gerrit
Code Review because we needed a way for engineers to get their code peer-
reviewed, and then submit it to a central repository that everyone else on
the team can go to obtain the reviewed trunk of the project from.

The biggest problem with any DVCS is "where is the trunk of this project".
When the project involves only 3 or 4 people, its easy for everyone to
declare that one user has the trunk on some machine, and that user just
pulls from the other contributors as necessary. When a project involves
30+ people working full-time for a company, often the company doesn't want
to pay a developer to sit there and pull from each person every day. Enter
the concept of a central repository that everyone gets read/write access
to. Its been that way since CVS/SVN/ClearCase, and will be that way far
into the future.

In my past I've also written an email-hook based review system around Git,
for a prior employer. It worked well-enough as you stated, but after using
something like Mondrian/Rietveld/Gerrit Code Review, I'm not sure I'd want
to go back. Editing comments and reading code in a syntax colored side-by-
side viewer is much easier than doing it in an email client against a
unified format patch. Especially when the change is large, such as 500+
lines and spanning 10 files.

Its quite unfortunate that Gerrit only works in the centralized approach
right now. I consider it to be a major design mistake. We cut some
corners early on and didn't make Gerrit properly support the DVCS model its
built on top of it. We are trying to fix those now, but its going to take
a while as its not our major focus. The plan is to:

- Make Gerrit easier to install.

If installation within your own user account can be reduced to
`sudo apt-get install openjdk-6-jre && wget gerrit.jar` then it
becomes more likely you might install it for your own use, even
if the upstream project doesn't use it. If the data store is a
local file in your home directory, with no database server needed,
its possible for the average user to run when they need to.

- Make Gerrit run on top of a distributed database.

My intern this past summer started a distributed database project on
top of git, called "gimd". In theory, if the comments are stored in
files in a git repository, you can share them through the same means
that you share the code itself. This should support a distributed
peer-review network.

- Add email interfaces to Gerrit.

Some people are just die-hard email fans. We should be able to
send them a unified patch by email from within Gerrit, but also
receive their reply and merge their patch comments back into the
side-by-side view of the Gerrit user. Just because you have to
work with a die-hard email user doesn't mean you should also have
to lose the features Gerrit offers.