There is Opera Critic [1], which was originally developed for working on the Opera web browser and subsequently open-sourced. I have used it (with a few patches) in conjunction with GitHub to fix many of the issues that are mentioned in the article. In particular it has the following features:
* Works with git. There isn't any VCS abstraction so if you want to use it with mercurial or whatever you're out of luck.
* The review tool (typically) owns the repository that code is pushed to (obviously this is a bit different when integrated with GitHub). Starting a review is typically something like "git push critic branch:r/branch".
* Because reviews are just branches you get all the features that the VCS implicity provides but patch based systems have to replicate (e.g. interdiffs) for free.
* Because reviews are just branches, multiple people can push to the same review so if you want e.g. a database expert to make the database changes for a particular change that is otherwise mostly written by a UI expert, that's possible.
* Assignment to reviewers is based on filters i.e. the tool picks the right reviewer for each change. There may be more than one reviewer for different parts of a single review request (e.g. where you have different owners for the database and ui code and a patch touches both those parts will be reviewed by different people). Reviews can be assigned to specific individuals when required.
* Review progress is tracked per commit and per file, so you can do long reviews in pieces rather than all at once.
* When issues are raised on particular lines of code it optimistically assumes that any subsequent push that touches those lines addresses the issue. If it wasn't addressed the reviewer reopens the issue. This works surprisingly well in practice.
* Rebases of the review branch are handled through "equivalent merge commits", which means that you retain all comments and progress from before the rebase.
* the UI is generally very "engineer designed" and won't win any beauty contests. But it has essential features that some other tools inexplicably lack, such as side-by-side diffs and syntax highlighting.
Agreed. Unfortunately no one involved with the project has the right combination of skills and motivation to do a nice introductory website. It's a pity because technically the tool is great, but the PR/design side is almost entirely lacking.
For the product that I'm working on, we are trying to take code reviews to another level by making it very easy for you to implement your own code review logic. We have what we call Smart Attributes, which are like metadata for your commits, diffs, etc., but unlike traditional metadata, they can be programmed in JavaScript to react to what they are attached to. In the following screenshot, you'll find an example of how you can use Smart Attributes to make code reviews a little more intelligent:
There is a Smart Attribute that has been programmed to track who has approved/rejected diffs at the file and directory level. You can find the source for this attribute here:
There is an attribute that has been programmed to run Google's style guide lint tool against C++ files in the code review. You can find the source for this attribute here:
With Smart Attributes, you can implement whatever code review logic you want. And if you've created a pretty useful one, you can share it with others or sell it, if you think somebody will pay for it.
Just to give a second opinion... I do not like working with Gerrit (I work with Android, for a HW vendor). In particular, reviewing one patch at a time becomes painful very quickly. Especially for complex features that end up having many changesets, because it's difficult to review what was changed in the newest changeset.
I would prefer having a branch to review rather than a single patch. When there are fixes, add a new commit to the branch and squash/rebase before merging to master. This way it would be easier to see what is happening during the development of a more complex feature with many rounds of review and fixing.
(note: we might not be using the latest version of Gerrit and our version control practices could be better)
On the third hand: while pushing a line of commits to Gerrit does create separate reviews for each, there's nothing stopping you from pulling the entire branch down and looking at it as a whole, as well as being able to make sure each individual commit makes some level of sense. I especially like how Gerrit+Jenkins lets you build every revision. I don't like the way that GitHub and similar tools (thinking specifically of Stash) make it more difficult to look at the individual commits.
I'm also a fan of Gerrit having to option to enforce fast-forwards, something GitHub doesn't allow: it will always make a merge commit, even if there's only one commit and its parent is HEAD of the branch being merged to.
There's ReviewBoard[1]. It has a pretty decent UI as code review tools go, and it's not tightly coupled to any particular VCS. That has the downside that you don't necessarily have some of the collaboration niceties that the likes of Critic has. It's easy enough to install into a virtual environment with virtualenv, so it's easy enough to try out without needing to run anything as root. It supports automatic assignment of reviewers based on certain criteria, such as the type of files being reviewed.
Atlassian Stash provides self-hosted git repository management that provides code review, and is getting better with every release. It is based on the concept of pull requests also but provides workflow better suited to teams, including the ability to require successful builds and reviewer approvals. In addition it has awesome diff views and a plugin architecture for customising behaviour and integrating with other development tooling.
* Works with git. There isn't any VCS abstraction so if you want to use it with mercurial or whatever you're out of luck.
* The review tool (typically) owns the repository that code is pushed to (obviously this is a bit different when integrated with GitHub). Starting a review is typically something like "git push critic branch:r/branch".
* Because reviews are just branches you get all the features that the VCS implicity provides but patch based systems have to replicate (e.g. interdiffs) for free.
* Because reviews are just branches, multiple people can push to the same review so if you want e.g. a database expert to make the database changes for a particular change that is otherwise mostly written by a UI expert, that's possible.
* Assignment to reviewers is based on filters i.e. the tool picks the right reviewer for each change. There may be more than one reviewer for different parts of a single review request (e.g. where you have different owners for the database and ui code and a patch touches both those parts will be reviewed by different people). Reviews can be assigned to specific individuals when required.
* Review progress is tracked per commit and per file, so you can do long reviews in pieces rather than all at once.
* When issues are raised on particular lines of code it optimistically assumes that any subsequent push that touches those lines addresses the issue. If it wasn't addressed the reviewer reopens the issue. This works surprisingly well in practice.
* Rebases of the review branch are handled through "equivalent merge commits", which means that you retain all comments and progress from before the rebase.
* the UI is generally very "engineer designed" and won't win any beauty contests. But it has essential features that some other tools inexplicably lack, such as side-by-side diffs and syntax highlighting.
[1] https://critic-review.org