News

Today's release of Review Board 2.0.2 brings a couple new features, some performance improvements, and several important bug fixes.

Earlier this week, we introduced per-user e-mail options in 1.7.26, which has now made its way into the 2.0 series. You can also now upgrade from a 1.7.26 release to 2.0.2 (sorry about that!).

We made some improvements to the API response times, which will benefit RBTools and much of the Review Board website. Along with this, we've done a lot of work to massively reduce the time it takes to update the search index.

The stars of this release, though, are the bug fixes:

• Clicking links and selecting text in editors now works as you'd expect.
• Replying twice to a review no longer keeps that draft banner sticking around.
• Solved some issues with fetching files on Mercurial repositories.
• Added some bullet-proofing for repository encodings.
• Attempting to reset user passwords no longer results in expired links.
• Lots of fixes to the administration UI.
• Much more!

Subversion in particular got a lot of love in this release:

• Verifying SSL certificates for HTTPS-based repositories now works again.
• The New Review Request page has been updated to properly filter commits based on the selected branch.
• PySVN is now the default backend again, but it's possible to choose your preferred backend.

See the release notes for the full list of changes.

Today's release of Review Board 1.7.26 fixes an important security vulnerability allowing attackers to craft very small JavaScript snippets in the diff viewer. If you're running 1.7.x, we recommend that you upgrade to this release immediately.

Along with that important fix, we have a new feature for you, and a small handful of bug fixes.

We adde a per-user setting that allows users to choose whether to receive e-mail from Review Board. This includes new and updated review requests, and discussions on review requests. If you're in the habit of checking the dashboard, and don't want to clutter your Inbox, this may be useful to you. Please note though that you'll still receive e-mail going to any mailing lists you're subscribed to.

There's also some bug fixes for CVS compatibility, API fixes for repository creation, encoding fixes for non-ASCII diffs, and more.

To upgrade to this release, run:

sudo easy_install ReviewBoard==1.7.26

See the release notes for more information.

Today's release of RBTools 0.6.1 fixes a number of bugs found in 0.6. These range from Review Board compatibility fixes and improved repository support to better error handling and fewer crashes.

There's also a few new additions:

• You can now set the "Depends On" list on a review request by passing --depends-on to rbt post.
• When running against the in-development Review Board 2.1 release, you'll be able to reliably post empty files (such as Python's __init__.py) for review, and apply them locally using rbt patch.
• rbt setup-repo is quite a bit smarter about finding your repository, especially when the paths differ in some way.

There's something for everyone in this release. If you've been running 0.6, you'll want to grab this one.

See the release notes for the full list of improvements.

Today, put out two new security releases of Djblets, our utility library for Review Board. These are versions 0.7.30 and 0.8.3, and fix a couple XSS vulnerabilities that were discovered in our Gravatar support and JSON serialization code.

We are strongly recommending that everyone upgrade to these releases, particularly if you're running a public Review Board server.

If you're running Review Board 2.0.x, you can upgrade by typing:

sudo easy_install -u Djblets

If you're running Review Board 1.7.x, you will need to upgrade by typing:

sudo easy_install Djblets==0.7.30

The Djblets 0.7.30 release has only been tested with Review Board 1.7.25. If you're on an older version, we recommend upgrading Review Board as well, to ensure better compatibility, and to benefit from the additional fixes in that release.

See the 0.7.30 release notes and 0.8.3 release notes for more information.

Earlier this year, we were proud to release our first commercial extension to Review Board, Power Pack. For the first time, documentation writers and developer teams could post and review PDF documents right from Review Board, without learning any new tools. Companies could bring GitHub Enterprise in-house without switching back to pull requests. Administrators could create a better experience by more easily scaling out across servers.

Since then, we’ve been working to improve Power Pack, listening to your requests and suggestions. Today, we’re happy to announce the beta program for our newest, most highly-requested feature: Power Pack Reports.

Get insight into your code reviews

Teams of all sizes can benefit from analyzing and measuring the effectiveness of code review amongst their developers. Better insight leads to better, more cost-effective processes and policies. To help with this, we're adding five different ways of looking at your code review process:

• Time to First Feedback

  This helpful graph shows how long, on average, it takes for new changes to be reviewed. See where the bottlenecks are in your team.

• Time to Close

  Some code reviews hang on for far too long, delaying releases. See how often this is happening, and where.

• Review Request Statistics

  A quick at-a-glance table showing statistics on how frequently team members post review requests, how many issues they typically have filed against them, and how many of those are dropped instead of fixed.

• Code Review Statistics

  More detailed metrics on the actual code reviews performed within the team. See who on your team are more actively reviewing code, how many issues they tend to find, and how frequently they mark Ship It! You'll have a better sense of who is really engaged in the code review process.

• Code Review Relationships

  This eye-catching diagram shows who's more actively reviewing who's code. It provides a great way of quickly seeing which parts of your team are working closely together, and who's not pulling their weight.

Try it out!

We have a lot of ideas in the works for this feature, but we want to get your feedback on the direction we're going.

If you think reporting would benefit your team, we'd love to have you as part of our beta! Your feedback will help to ensure this becomes an indispensable part of your code review process.

Please fill out our sign-up form to get started. We'll e-mail you as soon as the beta is ready.