What's New in Review Board

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.

We got a great response to last week's release of Review Board 2.0. We're happy to see that people were very receptive to the changes and improvements we made to the product. We also got some helpful, detailed bug reports.

Review Board 2.0.1 fixes a number of bugs and regressions found in 2.0. Most were minor, though some impacted installs and upgrades on some configurations.

Some of the highlights of this release include:

• Upgrades from pre-1.7 versions of Review Board should work better.
• Fixes for posting changes against Subversion and Perforce.
• Draft banners should no longer go missing.
• The "Last Updated" timestamp on review requests are now updated when posting reviews.
• Better memory performance for the condensediffs command.
• Improvements to extension packaging and media deployment.
• Visual tweaks in the diff viewer and My Account page.

See the release notes for the complete list of changes in 2.0.1.

We are very excited to announce the release of Review Board 2.0. This is our largest release ever, with lots of new features for end users and administrators, over 70 bugs fixed, usability and performance improvements throughout the product, and significant enhancements to our web API and extension framework.

There's way too much to talk about for this post. We'll simply go over some of the changes we've made to help the day-to-day life of software developers. The release notes will cover the rest.

The diff viewer is more powerful

So much of your time in Review Board is spent looking at diffs. We decided to make that time more pleasant.

We moved to a nicer look-and-feel with better readability, redesigned the revision/interdiff selector, added smarter moved line support and cleaner interdiffs, revamped the file listing (which introduces icons showing the complexity of changes), and introduced all-new indicators for showing indentation-only changes.

Review requests are prettier

The layout of review requests have been improved. The Description and Testing Done have been moved up, with the other fields moved to the right-hand side. This puts the most important information right in front of you, taking up less screen real-estate in the process.

We made it easier to see changes made to a review request. Newly uploaded diffs are shown with their file listings and change complexity icons. Text field changes are shown as unified diffs. Newly uploaded file attachments are shown as thumbnails. Et cetera.

"Ship-It!" is more meaningful

You'll now only see a "Ship-It!" in the Dashboard if all open issues have been addressed. Otherwise, you'll see an open issue count, letting everyone know that there's still work to be done.

If a reviewer opens issues and says "Ship It!" in the same review, the "Ship It!" won't be shown until the last open issue is closed.

Posting changes is easier

We've completely revamped the New Review Request page to make it easier to get changes into Review Board. In particular, it's easy to post existing commits from a branch on your repository without using RBTools, with just a couple clicks.

If you are using RBTools 0.6 or higher, you should find it's even faster to post your changes! There's also a few goodies in 0.6 for posting a commit's ID, and posting in Markdown format. Speaking of...

There's Markdown everywhere!

You can now use Markdown-formatted text in any text box, including the Description/Testing Done fields and in reviews or replies. This is particularly handy if you want to show off code samples, embed images, or list something in bullet point form.

What else...

• Built-in review for text-based file attachments.
• Search is now really easy to set up.
• An all-new My Account page, for selecting groups and updating your profile.
• A better-organized Dashboard, with support for bulk-closing review requests.
• Experimental Web Hooks for closing review requests when pushing related commits.
• High-DPI icons.
• Faster load times with fewer reloads.
• Many, many more improvements.

We didn't even get into the huge number of improvements to the web API and extensions, and all the performance and usability issues we addressed.

We want to thank everyone who helped make this release happen. Our contributors, beta testers, packagers, and of course, all the users and administrators out there who have provided great feedback and ideas over the years.

See the release notes for the full list of what's in 2.0. For any questions or concerns, please reach out to us on our community support list.

We’ve been working hard on fixing the bugs found by our beta testers, fine-tuning all the new extension support, and getting a few more experimental Web Hooks in place for more hosting services.

All around, it’s a good release. In fact, we were looking to call this the final 2.0, but we have a few fixes we want just a bit more testing on first.

Some of the key highlights of this release include:

• Fixes for upgrading from a pre-1.7 release
• Better protection from broken extensions
• Some new extension abilities for blocking publishing of review requests
• Condensing diffs no longer eats all available memory
• Lots of bugs squashed

The release notes have the full details, as well as installation instructions.

Our hope is to release the final 2.0 this month. A big thanks to all of our beta testers for providing such great feedback!

The Django project just announced a new set of security releases. We're putting out a matching Review Board 1.7.25 release that pulls these in, plus fixes for Active Directory and some documentation.

We recommend that everybody running 1.7.x updates to 1.7.25. If you're not ready to upgrade Review Board yet, you can instead upgrade to the new Django release by running:

$ sudo easy_install Django==1.4.11

If you're running the Review Board 2.0 RCs, you can instead upgrade Django by running:

$ sudo easy_install Django==1.6.3

The final Review Board 2.0 release will include these fixes.

See the release notes for the complete list of fixes.

Review Board 1.7.24 is out!

What? Another release already? Yes, unfortunately a couple problems were found in last night's 1.7.23 release, and we wanted to get the fixes out to you ASAP.

This fixes a crash with adding new repositories, and with displaying the Manual Updates page (triggered when Review Board detects a problem that must be fixed by hand).

The very brief release notes are available.

Review Board 1.7.23 is out. It’s a fairly typical bug fix release, with one addition that helps to address Heartbleed.

Heartbleed is the name for a widespread SSL security vulnerability found in OpenSSL and announced to the world on April 7th that can allow attackers to, in some cases, access private data in memory. It’s not specific to Review Board (and, in fact, the vulnerability lies outside of Review Board). Most Linux distributions are now providing patched OpenSSL packages, and the general recommendation is to re-issue your SSL certificates.

GitHub is recommending that users change their passwords and reset their authorization tokens. Review Board uses these tokens to communicate with your repositories on GitHub.

In 1.7.23, we’re providing a new management command for resetting your associated GitHub authorization tokens. You’ll need to know the password (and two-factor auth token, if enabled) for each linked account that you want to update.

To reset your tokens, install 1.7.23 and run:

$ rb-site manage /path/to/site reset-github-tokens

If you’re running an installation accessible over the Internet, you may want to have your users reset their passwords as well, to be safe.

Along with this, we have some authorization fixes for GitLab, and a few small bug fixes.

See the release notes for more information.

Oh man, do we have a great release for you today.

RBTools 0.6 has just been released, and it's a big one. We spent a lot of time simplifying the process for posting and updating review requests, and we think it's going to make life a lot easier for just about everyone.

Posting using Git or Mercurial used to require dealing with --parent and --revision-range, along with our custom revision syntax. Now all you have to do is pass native revisions or revision ranges to rbt post, like so:

$ rbt post HEAD
$ rbt post main-branch..feature-branch
$ rbt post 123:126

Compare this to the old way of doing things:

$ rbt post --parent=HEAD^
$ rbt post --revision-range=main-branch:feature-branch
$ rbt post --revision-range=123:126

We've also improved how "guessing" descriptions and summaries from commits work. In previous versions, you needed to run rbt post -g to enable guessing, but in 0.6, it's now automatic for new review requests. This means less typing and less work to do.

That behavior can also be changed through new GUESS_FIELDS settings in .reviewboardrc. This is covered more in the documentation.

A few other goodies:

• Feature and performance improvements for Mercurial
• Shelf support for Perforce
• Git repository hook scripts for auto-closing review requests and requiring approval for pushes
• Support for Markdown commit descriptions in Review Board 2.0
• Recording commit IDs in Review Board 2.0
• Many new configuration options

And more.

A couple important notes. We've removed support for the old post-review tool. Running post-review will now tell you to use rbt post instead.

We've also removed support for Python 2.4. You will now need 2.5 or higher. We strongly recommend that everybody upgrades to Python 2.7.

See the release notes for the complete list of changes.

Review Board 2.0 RC 2 is out, everybody! Thanks to all the great feedback from our beta testers, we were able to identify and fix the few remaining issues keeping us from a solid 2.0 release.

There's a bunch of fixes for little things here and there. Some polish, some performance enhancements, and a couple usability improvements. All in all, the release is feeling pretty stable, and we're feeling confident that the final 2.0 is just around the corner.

We also included a couple experimental feature additions from this semester's batch of students:

• The dashboard widgets in the administration UI can now be reordered through drag-and-drop, allowing you to see the widgets that are most important to you at a glance.
• We've added an experimental WebHook for those using GitHub. This hook will close any review requests referenced in a pushed commit, filling in the revision and branch where the commit landed. This requires a publicly-accessible Review Board install.

Along with this, we've made some nice improvements to rb-site. It has a new streamlined installation experience, as well as new management commands for working with installed extensions.

There's a few other goodies we've thrown in as well. See our release notes for all the details.