Review Board 1.7.20 is out. It's primarily a small bug fix release, fixing a couple crashes, reducing constraints on usernames, and fixing the annoyance with JSON fields in the administration UI.
It's a small release, but as always, we recommend it. The JSON fixes in the administration UI alone should solve a lot of issues people have been hitting.
See the release notes for more information.
Review Board 1.7.19 is out, with some bug fixes and support for GitHub's two-factor authentication.
In recent days, there's been a large number of attempts to compromise accounts on GitHub. By activating two-factor authentication, you can better protect your account.
Review Board was lacking support for their two-factor authentication, which was a problem when linking an account for a repository for the first time. The workaround was to temporarily disable two-factor authentication, but that's no longer necessary. When linking an account with two-factor auth for the first time, GitHub will send you an access code, which Review Board will prompt you for.
If you have already linked a GitHub account, you won't have to do anything more. We use revokable OAuth tokens when talking to GitHub using a linked account, which is separate from your auth credentials.
Along with this, there's a page caching improvement for review request pages, some usability fixes, and other bug fixes.
See the release notes for more information.
Just over 11 months ago, we released Review Board 1.7, which was a major evolution to the product. It introduced features like the extensions, a new administration UI, file attachment reviews and thumbnails, an issue summary table, and quite a lot of UI polish.
It was a pretty good release, but we’re announcing something better. Review Board 2.0 is coming.
We’ve released the first beta today, and would like to encourage people to give it a try. (Please do not try with a production install or database, though.)
Here’s some of the highlights for this release.
Create review requests from existing commits
The “New Review Request” page has been completely redesigned. On supported repositories and hosting services, a list of branches and their commits will be shown. Each commit can be quickly put up for review with just a single click. If your team commits changes to a branch for review, this will help tremendously.
Markdown in text fields
All text fields (Description, Testing Done, comments, reviews) now accept Markdown. This makes it really easy to show off sample source code (with syntax highlighting!) right in comments, or to express things with bullet points, add links, add emphasis, or to just in general structure your review requests or reviews better.
This won’t have any negative impact on any of your existing review requests or reviews, or your commit messages (when posting with rbt post or post-review). Only newly entered text will appear in Markdown.
All new diff file index
When viewing a diff, you’ll now get a much better idea of the complexity of the changes before you even look at code. The files are now each shown with a complexity graph, which is a little ring showing the relative number of inserts, deletes, and replaces, with the thickness of the ring indicating how much of the file has changed.
Along with this, little color-coded dots are shown for every chunk, linking to the matching chunk. It also shows whether the file was renamed (and what its old name was), and whether it’s a newly introduced file or a deleted file.
In our testing, we’ve found this very useful to help gauge how complex a change is before even digging into the change itself.
More intuitive revision selector
Our old revision selector was a hold-over from the early days. Not very nice to work with, and it took too long to switch revisions.
The new one is much more intuitive, and works as a slider. Simply drag the handles to the revision you want, or the revisions for an interdiff, and the diff will immediately load below. It’s fast and simple.
Less messy interdiffs
Interdiffs are fantastic, but can become a mess if there have been other changes to a file between revisions that aren’t related to the change going up for review. Update your tree, post another change, view an interdiff, and you’ll see junk.
No more. Interdiffs will, with few exceptions, only show what’s actually in your changes, making them more reliable than ever.
Smarter moved code detection
When moving code around a file, the diff viewer now does a better job both finding and showing blocks of code that have moved. They now appear as groups of moved lines, instead of a bunch of individually moved lines. It’s also better at not showing trivial moves.
More polished, faster UI
We’ve applied a lot more polish to the UI. The diff viewer, for instance, is a lot cleaner-looking. Many of the icons have been redone, and Retina versions have been created, so those of you on a MacBook Pro with a Retina display, you’re in for a treat.
More powerful extensions
Extension developers have a few new abilities to help in their creations. We’ve made it easy to package and test with static media files, right out of the box. We’ve also begun adding JavaScript-side extensions and hooks, which will make it easier in time to tie into more of the UI and operations in the browser.
Better performance
We’ve done a lot of work to reduce the amount of HTTP requests when accessing Review Board, to reduce reloads of pages (such as when publishing a reply or changing diff revisions), and reducing database queries throughout.
And much more…
A faster-loading Review dialog, better Git diff support, Markdown file review, file attachment thumbnails on comments, and many bug fixes.
We’re really excited about this release. It’s going to be amazing. This isn’t even all we’re doing for the release. By the time we ship 2.0, we expect to have support for image diffs and for extension-provided binary file diffs in the diff viewer. We’re working on a better layout for review requests. More extension support.
So give it a shot (on a test server!) and let us know how it goes!
For installation instructions and a full list of changes (with screenshots), see the release notes.
Unfortunately, yesterday's otherwise fantastic 1.7.17 release had a packaging snag that broke many installs. It's one we've seen before, and was due to a third-party tool we were using for building our JavaScript bundles, which has had a couple broken releases.
The new 1.7.18 release switches to using UglifyJS for JavaScript minification. This build should restore your installs to perfect working order.
Release notes are available.
We have a couple new releases of Review Board tonight. These both fix a couple security vulnerabilities discovered last night, and from this alone, we strongly recommend upgrading immediately.
The new 1.7.17 release also provides better GitHub integration, Local Site permissions, Extension improvements, and various bug fixes throughout the product.
Those using GitHub will have an easier time setting up new repositories (no more having to configure SSH keys!), and if anything goes wrong in the setup process, Review Board will do a better job of telling you what may be wrong.
If you're using the Local Sites feature, there's some improvements for you as well. Administrators of Local Sites will now have the ability to edit, close and reopen review requests, as well as post under another user's name, just like full-on administrators. These permissions are limited to Local Sites, of course.
We've also fixed some bugs around extensions. Enabling, disabling or changing an extension's settings will now cause the browser to re-fetch pages, instead of using old cached versions. Furthermore, extension customization now works with subdirectory installs.
The improvements in 1.7.17 are covered in more detail in the release notes.
If you're using the new Review Board Power Pack extension, or are looking to try it out, we recommend you update to 1.7.17. There are some fixes in this release that improve the interactivity with Power Pack.
If you're upgrading to 1.6.21, be sure to specify the version on the command line:
$ sudo easy_install ReviewBoard==1.6.21
Release notes:
Updated 30-October-2013, 12:05PM PST: Fixed the minimum Review Board version required. You'll need 1.7.14 or higher.
We're pleased to announce a release candidate for the Review Board Power Pack. While previous beta releases have been limited to people who signed up for our beta program, his release candidate is public, and anyone who is using Review Board is welcome to try it out.
The Review Board Power Pack is a set of advanced features to help you get even more out of your peer review system. If you'd like to check out what's included, see the Power Pack page.
If you're running a previous beta of the Power Pack, you should have received an email with detailed instructions on how to upgrade. If you're a new user, use the following instructions.
To get started, make sure you have Review Board 1.7.14 or newer installed. Then install the Review Board Power Pack by running:
easy_install -f http://downloads.beanbaginc.com/powerpack/ -U ReviewBoardPowerPack
Once that's installed, reload your web server, then browse to your administration interface and click "Extensions." You should see a single extension. Click "Enable" to activate it.
Once the extension is activated, you need to install a license. We've created a trial license which will keep things going until January 1, 2014. You can download this license at http://downloads.beanbaginc.com/powerpack/powerpack-trial.lic
Once you have the license file, click "Configure" on the extension. You should see a field where you can upload the license file to your Review Board server. Once you do this and save, you should see a trial license installed, and the Power Pack features will be enabled.
Any PDF files that are attached to a review request (with "Upload File") will then have a "Review" button which will take you to a document viewer. To add comments, simple drag across a region of a page like you would with an image attachment.
To add GitHub enterprise repositories, go to the "Add Repository" section in the admin interface. You should now see a new hosting service called "GitHub Enterprise". Configuration works just like GitHub.com, but you'll put your GitHub Enterprise server name in the form.
Setting up multiple front-end servers is a complex task, and we're working on some documentation about it. In the meantime, if you're planning on using the Power Pack for this, get in touch and we'll help you out.
We'd like to hear your feedback, good and bad. If there are any features that would be important to your organization, please let us know that too.
For any questions or comments, you can reach us at any time at support@beanbaginc.com.
Every once in a while, things just don't work the way they should. And with that, I bring you two new Review Board releases.
This fixes three main issues. First, the recent work on the API caused a breakage in the Review Group Users resource when looking up a user that was a member of more than one group. While this doesn't affect usage of Review Board itself, it does affect those who need that part of the API for their scripts.
Second, due to a regression in a tool we use for packaging, the Python 2.6 builds for Review Board 1.7.15 shipped with broken JavaScript files. We've reverted the version to the last known stable version.
Third, pagination in the dashboard was broken in 1.7.15. This was fixed last night with a new build of Djblets, and now this release depends on that newer version.
Along with these three fixes, 1.7.16 gained a couple new extension hooks for extension authors to play with, which add the ability to place menu items in the top-most bar, alongside the User and Support links. You can see this in action with the Review Board Chat extension.
Review Board 1.6.19 and 1.7.15 fix a few issues in the API where users could access certain data they should not have been able to access, if using the Local Sites feature, invite-only groups, or private repositories. It also fixes cases with invite-only groups where the group name and list of private review requests would show up on some pages (though the review requests themselves were not accessible).
These issues do not affect most of the installations out there, but we strongly recommend upgrading anyway. There are no known cases of anyone exploiting these bugs, and in fact we discovered these internally while building new tools to test for security vulnerabilities in our codebase.
There are also some other bug fixes, and important changes needed for extensions that provide their own REST APIs.
See the 1.6.19 and 1.7.15 release notes for more details on these releases.
We're up in Toronto today for the final day of the UCOSP Winter 2013 Sprint. Through UCOSP, we get to meet and work with bright and enthusiastic students pursuing careers in the software industry for a whole semester. Our students work on Review Board, building cool projects and getting a feel for what it's like in the industry. It's pretty awesome.
This semester, we have five new students: Allisa, Behzad, Edward, Elaine, and Natasha.
Allisa got into development at age 13 when she started writing custom maps for Neverwinter Nights. Now she's making it easy to do a security check of your Review Board installation to make sure you're safe from known configuration-related vulnerabilities.
Behzad got his start writing and modifying scripts for mIRC when he was 11. For this term, he's making our hidden trophy support less hidden by giving you a nice trophy case on your user page, showing every trophy you've earned. It'll even support the development of new types of trophies, even under extensions. (One may make the association between fish slaps and fish trophies?)
Edward's background was in systems engineering, until he found .NET and fell in love with programming. That led him toward going back for a CS degree. He's now taking a role on RBTools, adding some nice improvements. This includes extending 'rb patch' to be able to commit under the contributor's name (useful for open source projects) and adding a command to guide the setup of a new source tree.
Elaine used to want to be a writer, but found she liked writing code more than stories. She's working on an extension to help out when using checklists for code review.
Natasha got into CS after her first programming class in high school, because it fed her love of puzzles and problem solving. It also goes well with her coffee addiction. Her project's goal is to automatically suggest reviewers based on who has reviewed similar code in the past.
We were also joined by a former student yesterday, Yazan, who fixed a bug for us, and just generally hung around helping out.
UCOSP is a fantastic program, and we look forward to it every semester. We're super lucky to get such great students, and I'm really excited to see how far this new team will take the project.
Special thanks to Steven MacLeod and Mike Conley, our wonderful co-mentors who help make this happen every semester; UCOSP, who provide the opportunity for us to participate and meet such great students; and Mozilla, who provided the space for the sprint.
As we noted previously, there was a major Django security release announced. We're following that up with a new Review Board 1.7.14 release.
Along with updating to the latest Django release, we're also fixing a security issue in the API that affects those using access control on repositories and groups. It's possible to craft an API request that fetches reviews and some other information on review requests that shouldn't be accessible.
There's also support for Team accounts on Bitbucket, and a small handful of bug fixes.
See the release notes for more information.