Review Board and Bugzilla reviews, take 3

I’ve updated my review board setup once more (part 2, part 1).  The low barrier to entry is now even lower.  “How low?”, you might ask.  “On the ground!”, I might say.  “What other low low price features with big big value are on offer? With more facts and less spiel?”, you might then also ask…

  • It now works with patches that have a header.  Patches that were the result of an mq import and then directly uploaded will tend to have headers.  This was why sometimes patches would fail to import with unlikely errors about empty patches.
  • There is now a magic URL scheme that automatically pulls the patch, creates a review and bounces you to the review.  If the review already exists, it just directly bounces you.  That URL scheme is  There are no authentication requirements on using this URL nor viewing the diff or associated reviews.  However, if you want to actually use the review mechanism to make comments then you will need to login via OpenID.  See part 2 for more on that.
  • I modified johnath and Ehsan Akhgari’s magic bugzilla jetpack so that it also adds a “Review” link to patches.  My modified repo is here.  You can install it from here.  You can see what the word “Review” looks like up in the first screenshot.
  • I upgraded to the reviewboard git trunk.  This adds some improvements to the diff display such as showing you function context information, even if the patch did not include it.  (And even if it did, too.  A lot of patches involving C++ truncate the function signature, whereas as you can see in the screenshot, you get the full text!)  I believe it is also supposed to be clever about recognizing moved blocks.

Limitations and other notes:

  • Patch fetching is synchronous and can take a while because we also parse it all up before we return.  Do not sit there hitting reload.  We’ll give you an error message if it doesn’t work out.  Not a great one, but an error message nonetheless.
  • Patches are still assumed to be against mozilla-central or comm-central (depending on the bugzilla product) trunk as of the moment we fetch the patch.  This means bit-rotted patches that you are only looking at now may fail to apply.  At the same time, patches where you clicked on the link back when it was timely and go back to look at them now that they are going out of style are still going to be applied against the same revision they were in the first place.
  • The repo with my modified changes (on the bzreview-master branch) was nuked and re-created because of the svn -> git transition by the reviewboard people.  So if you previously pulled, you should probably blow your old repo away rather than end up with a weird hybrid mixture.  (btw, hg-git works very nicely, with the caveat that its bookmark-based representation of the git branching idiom confuses pbranch really quite badly.)
  • Ping me on IRC or drop me an e-mail if you are experiencing reliable problems after having determined that the patch in question is not just full of gibberish.

5 thoughts on “Review Board and Bugzilla reviews, take 3

  1. The short answer is yes, but most of the patches I see are either just the current mq patch contents or the current qdiff and this is a pragmatic incremental effort. The longer answer involves my concern that the parent changeset may not actually be from mozilla-central/comm-central proper and that could add additional failure modes. I also have some concern about not realizing the patches are bit-rotted and this behavior sorta plays to that 🙂

    Actually, I think non-git hg diffs may work correctly right now if they start with “diff -r” off the bat since they fallback to the traditional hg diff parser.

  2. Pingback: visophyte: data made shiny :: Tinderbox results in bugzilla, jetpack times 2, CouchDB, review board

Comments are closed.