In thinking about this, I realized that the comparison wasn’t really between Review Board and Splinter, but between Review Board and attaching patches in Bugzilla. You really have to look at the overall process. How do you go from a enhancement request or reported crash, to a first candidate code change, to reviews on that change, to a final version of your change, to pushing those changes to the official repository, to closing the original report? git-bz automates and makes convenient large sections of this. Splinter is just a solution for a gap in the process – how do you review a patch once it’s attached to Bugzilla? But Review Board replaces the entire thing: you don’t attach patches in Bugzilla, you just link to a review request that you’ve filed (with your patch) in Review Board.

First I should list some of the advantages that Review Board would bring to the overall process: first, it has a very slick and well developed web interface for reviewing and commenting on patches. The tool I’ve been working on is pretty nice for a couple of weekends of work, but there’s only so far you can go in a couple of weekends. Second, Review Broad has a very well-defined workflow. Each review request is submitted to a person or group for review. You are presented with your outbox: your patches waiting for review, and your inbox: patches that are waiting on review. With our Bugzilla, the process is buried in a large and complex user interface and is much less explicit. (Attachment flags can be used to do explicit review requests in Bugzilla, but we don’t use them on bugzilla.gnome.org.) Finally if we used Review Board for patch reviews in GNOME, we’d reduce the amount of noise for bug reporters. While I imagine it’s exciting to see two developers discussing obscure details of a patch to fix your reported crash, I also can imagine that it can be confusing and intimidating, and maybe people would prefer to just get a high-level summary when a patch was comimtted rather than all the details in their mailbox.

So, Review Board stacks up pretty well for web user interface and developer workflow. Where things become more problematical are the integration with Git and the integration with Bugzilla.

The normal way to interact with Git is from the command line, so any integration of a review tool with Git will start there. While the web portions of Review Board are highly advanced, the Review Board post-review command-line leaves a lot to be desired when compared to git-bz. It doesn’t follow the git command line conventions. It can’t take patches from Review Board and apply them locally. It can’t insert references to the review into the commit messages. And so forth. That’s partly a question of attention, and probably even more a question of being cross-version-control-system. There’s only so much you can do while handling Subversion, and CVS, and Git, and Mercurial, and …. Certainly a specific “git-rb” tool is possible that does many of the things that git-bz does is possible – the lack of such a tool isn’t an inherent defect of Review Board, just a current lack.

There is a more fundamental problem here – a review in Review Board is of a single diff (potentially with multiple revisions), but that’s not very natural to how people work with Git. More complex enhancements are almost always done as patchsets, with each patch in the set being kept as standalone as possible. In the Bugzilla/git-bz workflow, the entire set of patches attached to a bug logically makes up a patch set. git-bz makes it easy to attach a series of commits to a bug as patches or apply all the patches from a bug to a local branch. Individual patches can be commented upon, marked as accepted-commit_now, replaced with newer versions, but it’s only when everything has been agreed upon and pushed that the bug can is closed. Trying to handle this explicitly in the Review Board user interface would require some substantial changes: you’d want a Review Request to cover an entire patch set, but have Reviews apply to individual patches within it.

The issues with using Bugzilla and Review Board together lie both on the user side and on the infrastructure-development side. On the user side, there’s a simple but non-trivial problem that we’d suddenly have two different identifiers and URLs for the same issue – there would be the Bugzilla bug URL but also the review board review request URL. Which one should you reference in in your commit message? Which one do you search for? There would also be two separate accounts to deal with.

On the infrastructure side, there’s the standard work of installing, maintaining, upgrading, etc. Beyond that, we might want to try and figure out some sort of single-sign-on across Bugzilla and Review Board to help with the multiple accounts problem. We’d have to have some automated process to keep the repository list in Review Board in sync with the 600+ GNOME repositories and auto-create maintainers groups for the repositories. We’d need a bugzilla extension to link to reviews. We’d need a Review Board extension to update bugs in Bugzilla when a review was created.

My summary here is that moving GNOME to Review Board for patch review would be quite a bit of work and a substantial change in our current work habits. There would be significant advantages, but also some definite downsides in having to juggle two systems. If it’s possible to, with a small addition on top of Bugzilla, get a reasonable approximation to the web-based patch review aspects of Review Board without adding an entire second system, I think that’s pretty interesting. Once I put a demo of Splinter out there (days, not weeks), you can judge that “if” for yourself.

git bz attach http://bugzilla.example.com/show_bug.cgi?id=43215 HEAD

But that left a gap – once you were happy with the patch, how did you close the bug? You had to go back to your web brower, and twiddle a bunch of form controls. So, I’ve now added:

git bz push

Which looks at the URL that ‘git bz attach’ added to your commit message, finds the bug from there, and pops up a prefilled editor. It looks something like:

# Bug 43215 - Split HTTP communication out of Bug class - UNCONFIRMED
# http://bugzilla.example.com/show_bug.cgi?id=43215
# Enter comment on following lines; delete everything to abort

Attachment 892 pushed as f319ea4 - Split HTTP communication out of Bug class

# Comment to keep bug open
# possible resolutions: [F]IXED, [I]NVALID, [WON]TFIX, [WOR]KSFORME
Resolution: FIXED

# Lines below change patch status, unless commented out
# possible statuses: [n]one, [rev]iewed, [rej]ected, [c]ommitted, [o]bsolete
committed @892 - Split HTTP communication out of Bug class - none

You can just accept it, or you can make changes and add additional comment text. Once you exit the editor, the bug is closed and the attachments are marked committed.

Even more recently (just today) I implemented a feature request from Benjamin Otte for:

git bz push --fix 43215

This combines ‘git bz attach’ and ‘git bz push’ into one. So, to review, what it does is:

1. Rewrites the commit to include the bug URL
2. Attaches the commit to the bug, and marks it ‘committed’
3. Pushes the commit
4. Adds a comment to the bug and mark it resolved

The only thing it doesn’t do is mail your boss and ask for a raise.

Some of the other recent activity for git-bz:

• Fixed to work with new GNOME bugzilla
• ‘git bz edit’ – like ‘git bz push’, but not tied to a push. (So, you can just use it instead of the web when convenient.)
• Customizable “URL addition” -  you can have “Bug nnnn – ” on the subject line instead of an URL appended to the commit body.
• “URL addition” defaults to on, so you don’t have to remember to pass -u/–add-url
• No need to specify the bug # when re-attaching an updated version of a commit
• XML-RPC used for bug filing when available (improves error handling a bit)
• Chromium cookie-reading support (from Colin)
• Docs split out into a man page

As always, installation is trivial – just grab the script and put it somewhere in your path. (Or get the git repo URL from cgit, clone it, and symlink.)

# File the last commit as a new bug on the default tracker
git bz file my-product/some-component HEAD^

# Attach a series of patches to an existing bug
git bz attach bugzilla.gnome.org:1234 b50ea9bd^

# Prompt if you want to apply each patch attachment from a bug
git bz apply bgo:1234

Just the script: http://git.fishsoup.net/cgit/git-bz/plain/git-bz
GIt repository: git clone git://git.fishsoup.net/git-bz

I haven’t tested with anything but bugzilla.gnome.org yet; expect some things to need fixing.