I'm a comitter on the Review Board project as well as a Mozillian. I'll
reply inline to each of your points and compare Review Board to critic.
> It is probably not directly suitable for use at Mozilla
> since it assumes git is being used for code review and heavily depends
> on git features.
Review Board supports a number of repository types: git, hg, cvs, svn, bzr,
clearcase, perforce, and plastic. additional repository types can also be
added through extensions.
> From my point of view the most appealing features of critic are:
> * Trivial to start a review without leaving the command line. In critic
> a review is just a remote branch with a special naming convention.
> Therefore starting a review (at least when there is only one commit on
> the review branch) is possible without interacting with the web UI at
> all and without learning any kind of special tools. It simply looks like:
> git push --set-upstream critic HEAD:r/jgraham/my_review_name
Review Board is hands-off of your repository. It will only read, and the
workflow does not involve pushing commits, or committing to a central
There are two options for creating "review requests" in Review Board. One
is by using the actual web frontend to upload a diff, or select a range of
commits which have already been pushed. The preferred method is using the
command line client "rbt".
In the git case, to create a review request of your feature branch off of
master you would simply run:
$ rbt post
And to update an existing review request with a new patch you would run:
$ rbt post -r <review-request-id>
or more recently support for heuristically guessing the previous request:
$ rbt post -u
The "rbt" tool is part of the "RBTools"  package which is written in
python. RBTools also includes a python binding for the Review Board REST
API, and new commands can be plugged in by third party packages.
So, while using Review Board does require learning a new tool, that same
tool is used for all repository types, and is extensible (mach commands
could even be written to take care of posting review requests for bugs
> * Trivial to update a review from the command line. Updating a review is
> simply a case of pushing more changes to the review branch. Again there
> is no new tool to learn other than the VCS. This also means that it is
> very easy for multiple people to contribute to the same review branch,
> making collaborative changes easier.
Like previously mentioned, rbt takes care of updating.
Review Board currently supports only a single "owner" of a review request,
so collaboratively updating that request isn't supported.
> * Automatic identification of reviewers for a change. Instead of making
> it the requestee's responsibility to know who owns the code that they
> are changing, critic requires code owners to register themselves as
> reviewers for specific parts of the tree. When a review comes in
> everyone who owns one or more files touched by the review is assigned as
> a reviewer for the subset of the changes in files they own. There are
> then manual overrides for these defaults which can be used to e.g.
> assign one specific person as the reviewer for a particular review.
Review Board can automatically assign "Review Groups" or specific users
to a review request based on the files touched, or repository being
referenced. These groups must have users manually added, and the rules
for automatically assigning groups must be created manually.
A suggestion feature for reviewers (similar to bugzilla's) is currently
in the works, but is not complete. I feel at Mozilla this information
might be taken care of in Bugzilla anyways?
> * Great diff support. Because critic has access to the whole repository
> including all commits on the review branch, it isn't limited in the way
> that a static diff based tool often is. In particular one can view
> interdiffs (these are just the individual commits), or the sum of any N
> contiguous commits in the review branch, right up to the whole review
> branch squashed into a single diff. Diffs can also be expanded in place,
> and the whole tree can be browsed with the changes applied.
Review Board generates and displays very nice diffs . Review Board
differs from critic here, as it deals with "patches" instead of commits,
so the interdiffs it generates are between versions of patches uploaded.
For example, I create a review request with a patch. It is reviewed, and
I update the patch with changes. Review Board will then allow you to see
the differences between the old patch, and the new patch (You can actually
ask for the interdiff between any two versions of the patch).
Another feature is things other than diffs are also reviewable. Review Board
supports displaying and commenting on regions of images and other file types.
> * Side by side diffs. Sounds obvious, but, incredibly, GitHub doesn't
> have it… Also, highlighting of common errors like trailing whitespace in
> the diff.
Review Board uses side by side diffs. Trailing whitespace highlighting can
be turned on or off.
Also, Review Board will highlight not only changes to lines, but the smaller
portion which was actually changed on the line (you can see this as a darker
yellow highlighting on some of the modified lines in )
Another cool feature of Review Board, is detection of moved lines. If a
section of code was deleted in one part of the diff, and added somewhere else,
Review Board will annotate the deletion and addition as a move, saying where
it was put or came from ( also includes an example of this).
> * Differentiation between "issues" and "notes". With a review there are
> often "must fix" items and general comments that might not need a change
> for the review to be accepted. Critic calls the former "issues" and the
> latter notes.
Review Board uses "issues" and "comments". When you make a comment on part
of the code, you may opt to open an issue. These issues are tracked, and
the review request owner has the option to "fix" or "drop" them.
> * Automatic tracking and updating of review progress. Every time that a
> change to a specific file in a specific commit is reviewed — whether or
> not there were issues found — it is marked as "reviewed". This is used
> to give an indication of the overall progress of the review, and to
> allow collaborative review. In addition the number of outstanding issues
> is tracked so it is clear what remains to be addressed. Together these
> mean that there is no need for a final "r+"-type comment; the review is
> done when all commits are reviewed and there are no remaining issues.
Review Board doesn't track review progress automatically. The workflow that
Review Board development uses is comments are made and issues are opened
until a patch is posted that the reviewer is happy with. Then they click
the "Ship-it" checkbox when publishing their review, which marks that
review as signing off on the code.
> * Automatic marking of issues fixed when the line(s) they refer to are
> changed. Critic is optimistic about issues getting fixed; it assumes
> that any new commit that touches a line with an issue filed against it
> probably fixes that issue and closes the issue. If this is not in fact
> the case it is the responsibility of the reviewer to reopen the issue
> against the new code. This turns out to be a great default because it
> significantly reduces the amount of tedious make-work that the review
> system imposes.
Review Board does not do this automatically. It is the responsibility of
the review request owner to mark issues as "fixed" as they fix them. I
actually use this as a sort of checklist, and mark each as fixed as I
fix them, and then post the new patch once I have fixed all of the issues.
> * Support for merges and rebases. In particular critic allows review of
> the way that merge conflicts are resolved. Rebases are handled in terms
> of an "equivalent merge commit" and so can be reviewed in just the same
> way. Modifying branch history (e.g. squashing several commits together)
> is also supported. Issues are not lost in the face of this kind of
> history modification.
Since your aren't pushing commits, you can merge / rebase all you want
locally, and just post the diffs to Review Board. If you would like to
review a merge, it can be posted as a diff before or after pushing.
> * Batched notifications. This is, again, as a counterpoint to GitHub
> which produces one email per change; a setup which is unbelievably
> spammy. Critic allows multiple changes to be made to a review, and then
> the whole lot sent at once, so that the amount of mail is kept to a minimum.
Notifications are batch in Review Board. This is dealt with using "drafts"
for everything. When you're making a review, you can modify it throughout
updating your draft, and then you eventually "publish" it, which sends
a notification and posts it publicly. Replies to reviews also use drafts.
> * Extensible. Critic allows writing extensions in js, which can be used
> to add (preject-specific) support for bug trackers, editors, build
> systems, etc.
Review Board supports both python extensions to the backend which can
modify the HTML, CSS, JS which Review Board outputs (Among many other
things), and front-end js extension support.
There is also support for extending review board to review other file types.
For example, there is a (commercial) plugin  for Review Board which allows
reviewing pdf files directly in the browser.
> If you want to see a critic instance, there is one that we use for
> reviewing web platform tests tests at . Note that login is via github
> credentials (using OAuth) and that because of the way this integrates
> with GH, some of the details around e.g. creating a review are slightly
> different (you push to GH, not to the critic instance directly, for
> example). Also note that some people are significantly put off by the
> clearly engineer-designed UI. This is not a fair proxy for the overall
> quality of the tool. My version is also slightly old and doesn't have
> extension support enabled.
Review Board design strives to be as simple and usable as possible, you
can look at  for examples of the interface.