Finally, definitive proof that when I don't sleep, good things happen.
Tonight (this morning?) we've released Review Board 1.6 beta 1, and there's a lot of awesome things for users and administrators alike.
Prior to 1.6, administrators that wished to limit access to repositories for different users (say, main engineering and contractors) would need to set up different Review Board deployments, which means double the maintenance and upgrade work. Anyone with access to a Review Board server had access to everything on it. No longer.
1.6 introduces access control, allowing administrators to create invite-only groups, hidden groups, and limit repository access to certain users/groups. These are all set up on the Group and Repository database pages in the administration UI. Now, you can ensure that people have access only to what they're allowed access to.
We've put together a special form of access control: Local site divisions. This is a special feature still undergoing development. it allows a single Review Board instance to be split up into different divisions that each have their own list of users, repositories, groups, and review requests. Handy for giving QA, engineering, and contractors their own separate sites, for instance. Users can only view their site (and therefore the dashboard, review request lists, groups, repositories, etc.) if they belong to that site, and it's up to administrators to decide that. This is an experimental feature and will undergo continued development over the next couple releases.
On top of all that, we've greatly enhanced our authentication backend support. Companies or organizations who have developed custom authentication backends in the past know how much a pain it is to use them with Review Board. We've fixed that in 1.6. Review Board now scans for authentication backends that comply with the new API and shows them in the list alongside Active Directory, LDAP, etc. Authentication backends can provide their own settings forms, can list the things they support (changing e-mail addresses or passwords, for instance), and then handle those types of changes.
Not to be left out, we have some great features for users as well. One-click Ship It!, collapsible reviews, Plastic SCM support, improved user pages, and user info bubbles, just to name a few.
For the full list of features in 1.6, see the release notes.
Our goal is to get through the beta cycle fast and get the final 1.6 release out the door in a couple months time. If you're planning to beta test 1.6, please let us know if you run into any problems (or even if things are working well).
Review Board 1.5.4 is out the door, with some good bug fixes and new API functionality some people have been asking for.
We've extended the new API to bring back support for updating change numbers on review requests, and to update review requests based on change numbers. The next release of post-review will use this when working with Perforce.
There's also new API for creating, modifying, and removing repositories, which should help for large deployments tracking hundreds of Git repositories. The Repository API documentation go into some detail on this.
Along with that, we have several small fixes for problems reported since 1.5. Most only affect certain users.
Release notes are available with the complete list of fixes and improvements.
Perforce users who switched to Review Board 1.5.2 and RBTools 0.3.1 this week hit an unfortunate problem updating review requests with change numbers. It turns out there's a validation error in our new API involving change numbers, which we'll be getting to soon.
For now, RBTools 0.3.2 is out the door, and works around this breakage by falling back to the old API. If you're on Perforce, you'll want to upgrade and make sure things are back to normal. Sorry about that!
There's also a fix for parsing CVSROOTs that don't have a username in the path, and choosing Mercurial over Perforce in a Perforce repository when there's an existing Mercurial user configuration.
Another release tonight! This time, Review Board 1.5.3.
After our 1.5.2 release, some users hit issues with the new SSH infrastructure. In particular, Windows users, CVS users, and Bazaar users hit different problems. We've ironed them out and put together a new testing infrastructure here to make sure they keep working. If you've been bitten by 1.5.2 and SSH, please try this release out and let us know how it goes.
Along with this, we've updated our API so that RBTools 0.3.1 (and any other clients) can use a repository name instead of a path when creating a new review request. This greatly simplifies setting things up when there are lots of possible repository paths involved. See the RBTools 0.3.1 release announcement for some more information on this.
There are also a few other fixes thrown in. See the release notes for more information.
RBTools 0.3.1 is out the door, with an important crash fix for users running Review Board versions older than 1.5.2, and a brand new feature sure to make administrators a bit happier.
Starting in 0.3.1, .reviewboardrc has gained a new configuration option, REPOSITORY. This can be used to override what repository information is sent to the Review Board server when creating a new review request. You can give it a different path, or, with the upcoming Review Board 1.5.3, you can give it the name of the repository (the same name you'd see for it in the New Review Request page).
This is particularly useful when repositories are SSH-backed and include a username. If you have more than two possible paths to a repository, you can choose the one to send to the server with this setting. Your upstream repository you want to use may be svn+ssh://bob@example.com/var/lib/svn, but your users may be using their own usernames instead of "bob." In these cases, you can set something like the following in your project's .reviewboardrc:
Tonight we released RBTools 0.3, the latest and greatest update since 0.2. RBTools, aka "That thing post-review lives in," supports the new API in Review Board 1.5.x and contains fixes and enhancements for CVS, Subversion, ClearCase, Mercurial, Perforce, and more.
The are so many improvements in this release, but two big highlights I'd like to point out are the support for the new Review Board 1.5.x API, and the addition of Plastic SCM support.
Review Board 1.5.x's new API is extensive, and we're working to make RBTools take advantage of it. To start with, we've updated post-review to make use of it, which is important because the old API is going away in the upcoming Review Board 1.6 release. The plan is to introduce new scripts alongside post-review that call into the new API, replicating nearly all of the web UI's functionality from the command line. At the same time, we'll have a Python API that developers can use to talk to Review Board. All this will happen for the RBTools 1.0 release.
As I mentioned, we received Plastic SCM support by way of Dick Porter, one of the Plastic SCM developers. This is a new cross-platform DVCS provided by Codice Software, with professional and community editions. It's meant to work with the Plastic SCM support going into Review Board 1.6. If you're using Plastic SCM, you should be able to start using Review Board and Plastic SCM together soon.
There was also a big push for improvements to ClearCase, Mercurial, and Perforce. I'd like to thank Jan Koprowski for the ClearCase work, Dan Buch for Mercurial, and Ben Hollis for Perforce. And of course, there were many other contributors with critical bug fixes and enhancements in this release.
For the full list of changes and contributors, see the release notes.
Please note: If you're using Review Board 1.5.x and after upgrading to RBTools 0.3 you can't log in, you may have an incompatible WSGI configuration. Please see the FAQ entry on fixing this.
Happy New Year, everyone! Hopefully everyone's had a good holiday and start of the new year. We've been hard at work through the holidays on many improvements to Review Board, and tonight have released 1.5.2.
Review Board 1.5.2 is a fairly substantial and critical feature and bug fix release. It fixes many of the problems developers have encountered with the new API we introduced in 1.5, particularly with authentication. Developers working with our API should consider the 1.5.2 release to be the minimum requirement from here on out.
If you're using WSGI, it's very important that you read the release notes for updating your configuration, or you'll hit problems with the API in the future.
Administrators trying to set up SSH-backed repositories, particularly private GitHub repositories (both standard and GitHub Organizations) should now have a much easier time getting going. We've introduced SSH key management to make it easy to generate new SSH keys, upload existing ones, or view the public key for an existing key. Review Board will be able to use the configured SSH key to access SSH-backed repositories without having to change the home directory for the web server's user.
There are many other fixes in this release. I've only mentioned a couple of them. See the release notes for everything else in this release.
Starting in September of this year, we've been participating in UCOSP (Undergraduate Capstone Open Source Projects), a wonderful program similar to Google's Summer of Code where students at various universities in Canada participate in open source projects for school credit for four months.
This term, we had six fantastic students working on a variety of exciting projects, many of which are landing in the upcoming 1.6 release. They just wrapped up with some screencasts demoing all the work they've done. I'd like to introduce these students and share these screencasts. In no particular order...
Kevin Quinn
Kevin worked on a variety of usability enhancements to the web UI:
Entering an invalid user or group in the reviewer list now presents a temporary inline error message telling you that the user/group wasn't found. It was easy before to typo a name and not realize you've done that right away, and this should solve that problem.
Old reviews are now collapsed, shortening long review request pages. The way this works is that any reviews that you have already seen that predate the most recent update to the review request will be collapsed, unless that review has had a reply since you last visited the page. Any collapsed review can be expanded to see the full discussion.
A new one-click "Ship It!" button was added next to the "Review" button that makes it dead simple to post a review that approves the change. This is great when you don't have any comments, as it speeds up giving approval on the review request.
The user page has been vastly improved. Currently, when viewing the page for a user, we only show the outgoing review requests, but with Kevin's new change, we now show some information about the user, as well as their Gravatar.
When hovering over a username (both the the review request's submitter name or the author of a review), a little info bubble pops up with some information on the user. This is a mini version of the user page, and is extremely useful information to have on hand.
Wow, that's a lot of nice additions. In his own words:
Lianne Lavole
Lianne's project was to take the existing code for Webhook support written during Google Summer of Code two years ago and package it into an extension. This was originally developed as a piece of Review Board, but we decided it would be better off as an optional extension. Lianne's project was a good test of our extension framework, and gets us a huge step closer to making Webhooks available for everyone. Of course, because it's an extension, it requires the experimental extensions branch, which we'd like to focus on after 1.6.
For those not familiar with Webhooks, they're a mechanism that sites can use to notify other sites or scripts when some event has taken place, using HTTP POST requests to one or more URLs. For example, posting a new review request could post an update on some internal dashboard, or on Twitter, or to CIA. This should be a useful feature for many admins and projects out there.
Awesome, isn't it? I'm personally looking forward to using this in our project's own Review Board install.
Lindsey Sawatzky and Brendan Curran-Johnson
Lindsey and Brendan worked together on a joint project to provide a full-fledged Python client API for Review Board. Today, any clients out there have to hand-roll their own support for our APIs, including our own post-review script. By providing an actual API, third parties, and ourselves, will be able to do more integration with Review Board.
Along with the new API, they also developed several new utility scripts for working with review requests. These will serve as a replacement for post-review, eventually. For example, they have scripts to open review requests, close them, create and update, upload screenshots, apply patches to the working tree, and more.
The scripts work like git commands, for those familiar with them. There's a main "rb" script, and the first parameter to it is the actual command to use. These can even be custom ones in your path, making it easy to create scripts that naturally fit in with our own collection of scripts.
We'll be getting this into a future release of RBTools, and migrate post-review over to using it. Should make your custom hook scripts and other points of integration way easier to write!
Laila Agaev
Laila had two projects this term. The first will put a smile on any Windows Review Board administrator's face. She has written a full Windows installer for Review Board, making it easy to get up and running face with minimal fuss. It handles the installation of the various bindings for databases, code repositories, and more. I'm hoping we can make this official in our 1.6 release.
Her second project was file upload support. With her change, you can upload any type of file into Review Board, download the files, and comment on them. It's a much requested feature. Developers could upload artwork associated with the change to open source projects, or log files for unit tests, or whatever.
I know some companies have been asking for this for quite a while, so we'll work to get this into 1.6.
Hongbin Lu
Hongbin worked on another often-requested feature: the ability to update bug trackers when a review request is created. This is an extension that works with Google Code and Bugzilla (with some optional Bugzilla plugins installed) and can update any associated bugs when a new review request is created or when a review request has been updated to point to a bug.
Again, since it's an extension, people will have to wait for the extensions branch to land, but hopefully that'll only be in another release or two. I expect bug tracker integration to be one of the top downloaded extensions then.
Thanks!
I want to thank all our students for their hard work this term. You've all done excellently and I'm thrilled that so much has been accomplished this term.
Special thanks to Mike Conley. Mike was a student in the last Google Summer of Code, and took on most of the mentorship and coordination in UCOSP on behalf of Review Board this term. I don't know how we would have ever done it without you, Mike!
And of course, thanks to Karen Reid, Andrew Louis, and everybody else at UCOSP! We loved participating this term, and greatly look forward to next term!
Review Board 1.5.1 has been released. It's a small bug fix release that fixes a few small problems, including lighttpd installation, serialization problems with the API's XML output, breakages with SCons files, and better error reporting for Git repositories with incorrect permissions, to name a few.
It's a pretty small, safe release with no real emergency fixes, but it's worth an upgrade, particularly if you're affected by one of the problems.
Review Board has been in development for almost four years now, and in that time we've seen a lot of growth in the project, and have brainstormed exciting directions to take it.
To that end, we're proud to announce Beanbag, Inc. We formed Beanbag to maintain Review Board and to better help fund it in the future by developing services and software around it.
We're starting small. Beanbag is owned and operated solely by David Trowbridge and myself (Christian Hammond), and will remain that way for the foreseeable future. Long term, we're hoping we can start doing even more with Review Board to help address developers' needs.
As for Review Board itself, nothing is changing with the goals or the way it's run. Our own personal copyright on the project is transitioning to the new company. Otherwise, the project is staying the same. It will still be open source under the MIT license. We will still do active development on it. It's the same project you (hopefully) love, with the same people running it.
Our first big Beanbag project is our upcoming Review Board hosting service for small businesses, RBCommons. We will be providing shared and private hosting for organizations and businesses for a reasonable monthly fee. We'll take care of installation, upgrades, and maintenance. If you're interested in this, you can sign up on the RBCommons site to be notified, and we'll let you know as soon as we begin alpha testing.
