Review Board

After nearly two and a half years of development, over 2000 commits, and contributions from over 120 people, we are proud and excited to bring to you the culmination of our work: Review Board 1.0. A lot has been put into this release. There were ... [More] many times in the past where we wanted to just get 1.0 out the door, but decided to wait until the time was ready. We believe it was worth the... [Less]

Today brings what should be the final RC release before Review Board 1.0! RC2 introduced a slowdown with a particular SQL query on the All Review Requests page that caused problems on large installations. Not only has that query been fixed, but ... [More] further optimizations have been made to our queries to speed up the dashboard and other pages even more. At this point, we're confident in our 1.0... [Less]

It seems a few bad bugs snuck into RC1 that affected many users. Thanks to everyone who tested RC1 early and let us know! We've just released RC2, which should prove to be a much more reliable release. We will probably put out one more RC ... [More] release after this, which will improve installation on Windows and fix any remaining showstoppers. We'll then release 1.0 shortly after. Bugs Fixed: ... [Less]

Update: There's a known bug in RC1 where rb-site install will fail on a fresh new install. We will have a new release soon, once we make sure there aren't any other major regressions. You can either attempt to install a previous beta and then upgrade ... [More] to RC1, or you can use the May 4th nightly by running: easy_install -f http://downloads.review-board.org/nightlies/ -U ReviewBoard One more giant... [Less]

Review Board: Summer of Code, Roadmap and Future Plans

Summer of Code This year, we (the Review Board project) was given the opportunity to participate in Google’s Summer of Code. We’ve received some great student proposals so far, and I think we’ll see exciting work done on Review Board this summer. ... [More] The deadline for Summer of Code is coming up fast (April 3rd, 19:00 UTC). If you’re interested in working on Review Board and haven’t yet applied, it’s not too late, but you’ll want to hurry. Skim through our ideas page and, if you find something interesting or have a great idea not listed here, then apply and tell us your plans. I can say we’ve received several proposals so far for the installer and admin UI, so unless you feel strongly about either of those, you’ll increase your chances with other proposals. We’re also offering free Review Board hosting for open source projects participating in Summer of Code. If you’re a mentoring organization and would like to give Review Board a try for reviewing and managing student code, go ahead and contact us and we’ll get you set up. Roadmap We’re finally nearing 1.0. We recently put out our 1.0 beta 2 release and are now in a feature freeze. We’re working to get some bug, performance and usability fixes in for beta 3, which I’m shooting for in a few weeks. Then we’ll branch for 1.0, put out a Release Candidate or two, and then finally release 1.0! There’s a lot of really cool features planned after 1.0, namely extensions and policy customization. Extensions Our bug tracker is filled with feature requests for all kinds of things, ranging from bug tracker integration, instant messaging, a method for offering bribes for code reviews, and so on. We clearly can’t put all the requested features in the codebase, so we’ve decided instead to add support for third-party extensions. Coming soon, developers will be able to write extensions to Review Board in the form of Python modules to extend or alter the functionality of Review Board. The extension framework will allow them to do the following: Access the database using the existing Review Board database models. Add new database models for storing data. Listen for signals (new review request published, review request submitted, etc.) and act on them. Add custom URLs. Replace existing URLs, for advanced capabilities such as replacing the diff viewer. Add new API handlers. Add “action” links to existing review requests and reviews. Add columns and sidebar entries to the dashboard. Add pages to the administration UI. Communicate with other extensions. Provide a settings page, which stores data in Review Board-provided models (we even auto-generate the settings page for the extension by default). And more! A lot of this already exists in a private development branch, and it will be one of our primary focuses as soon as 1.0 goes out. In time, we’ll add a new section to the Review Board website where developers can list their extensions for download and for sale. Administrators will be able to browse and search for extensions directly from the administration UI and install them without having to even open a terminal (in most cases). We’re hoping this will solve a lot of in-house integration issues. For example, many companies have custom sandbox architectures, bug trackers, and statistics software which they’ll now be able to tie in with Review Board. Policy Customization We’ve found that a lot of companies have very specific ways they want to handle policy and access restrictions. For example, many companies want to limit who can see certain parts of a repository (and therefore certain diffs), or want to allow anybody to create review groups, or want to disallow people from joining review groups. Some also want to dictate what constitutes approval for submitting a change. We’re looking into the various requests and attempting to come up with a policy model that is flexible enough to handle these needs. One of the ideas is to provide some basic level of access control on a per-repository, per-path, and per-group basis. We’d then piggy-back on the extension framework to allow for more specific policy control. The advantage is that developers could write their own policy rules that interface with some part of their company’s infrastructure. If people have any input on this, we’d love to hear it. [Less]

Summer of Code This year, we (the Review Board project) was given the opportunity to participate in Google’s Summer of Code. We’ve received some great student proposals so far, and I think we’ll see exciting work done on Review Board this summer. ... [More] The deadline for Summer of Code is coming up fast (April 3rd, 19:00 UTC). If you’re interested in working on Review Board and haven’t yet applied, it’s not too late, but you’ll want to hurry. Skim through our ideas page and, if you find something interesting or have a great idea not listed here, then apply and tell us your plans. I can say we’ve received several proposals so far for the installer and admin UI, so unless you feel strongly about either of those, you’ll increase your chances with other proposals. We’re also offering free Review Board hosting for open source projects participating in Summer of Code. If you’re a mentoring organization and would like to give Review Board a try for reviewing and managing student code, go ahead and contact us and we’ll get you set up. Roadmap We’re finally nearing 1.0. We recently put out our 1.0 beta 2 release and are now in a feature freeze. We’re working to get some bug, performance and usability fixes in for beta 3, which I’m shooting for in a few weeks. Then we’ll branch for 1.0, put out a Release Candidate or two, and then finally release 1.0! There’s a lot of really cool features planned after 1.0, namely extensions and policy customization. Extensions Our bug tracker is filled with feature requests for all kinds of things, ranging from bug tracker integration, instant messaging, a method for offering bribes for code reviews, and so on. We clearly can’t put all the requested features in the codebase, so we’ve decided instead to add support for third-party extensions. Coming soon, developers will be able to write extensions to Review Board in the form of Python modules to extend or alter the functionality of Review Board. The extension framework will allow them to do the following: Access the database using the existing Review Board database models. Add new database models for storing data. Listen for signals (new review request published, review request submitted, etc.) and act on them. Add custom URLs. Replace existing URLs, for advanced capabilities such as replacing the diff viewer. Add new API handlers. Add “action” links to existing review requests and reviews. Add columns and sidebar entries to the dashboard. Add pages to the administration UI. Communicate with other extensions. Provide a settings page, which stores data in Review Board-provided models (we even auto-generate the settings page for the extension by default). And more! A lot of this already exists in a private development branch, and it will be one of our primary focuses as soon as 1.0 goes out. In time, we’ll add a new section to the Review Board website where developers can list their extensions for download and for sale. Administrators will be able to browse and search for extensions directly from the administration UI and install them without having to even open a terminal (in most cases). We’re hoping this will solve a lot of in-house integration issues. For example, many companies have custom sandbox architectures, bug trackers, and statistics software which they’ll now be able to tie in with Review Board. Policy Customization We’ve found that a lot of companies have very specific ways they want to handle policy and access restrictions. For example, many companies want to limit who can see certain parts of a repository (and therefore certain diffs), or want to allow anybody to create review groups, or want to disallow people from joining review groups. Some also want to dictate what constitutes approval for submitting a change. We’re looking into the various requests and attempting to come up with a policy model that is flexible enough to handle these needs. One of the ideas is to provide some basic level of access control on a per-repository, per-path, and per-group basis. We’d then piggy-back on the extension framework to allow for more specific policy control. The advantage is that developers could write their own policy rules that interface with some part of their company’s infrastructure. If people have any input on this, we’d love to hear it. [Less]

Summer of Code This year, we (the Review Board project) was given the opportunity to participate in Google’s Summer of Code. We’ve received some great student proposals so far, and I think we’ll see exciting work done on Review Board this summer. The ... [More] deadline for Summer of Code is coming up fast (April 3rd, 19:00 UTC). If you’re interested in working on Review Board and haven’t yet applied, it’s not too late, but you’ll want to hurry. Skim through our ideas page and, if you find something interesting or have a great idea not listed here, then apply and tell us your plans. I can say we’ve received several proposals so far for the installer and admin UI, so unless you feel strongly about either of those, you’ll increase your chances with other proposals. We’re also offering free Review Board hosting for open source projects participating in Summer of Code. If you’re a mentoring organization and would like to give Review Board a try for reviewing and managing student code, go ahead and contact us and we’ll get you set up. Roadmap We’re finally nearing 1.0. We recently put out our 1.0 beta 2 release and are now in a feature freeze. We’re working to get some bug, performance and usability fixes in for beta 3, which I’m shooting for in a few weeks. Then we’ll branch for 1.0, put out a Release Candidate or two, and then finally release 1.0! There’s a lot of really cool features planned after 1.0, namely extensions and policy customization. Extensions Our bug tracker is filled with feature requests for all kinds of things, ranging from bug tracker integration, instant messaging, a method for offering bribes for code reviews, and so on. We clearly can’t put all the requested features in the codebase, so we’ve decided instead to add support for third-party extensions. Coming soon, developers will be able to write extensions to Review Board in the form of Python modules to extend or alter the functionality of Review Board. The extension framework will allow them to do the following: Access the database using the existing Review Board database models. Add new database models for storing data. Listen for signals (new review request published, review request submitted, etc.) and act on them. Add custom URLs. Replace existing URLs, for advanced capabilities such as replacing the diff viewer. Add new API handlers. Add “action” links to existing review requests and reviews. Add columns and sidebar entries to the dashboard. Add pages to the administration UI. Communicate with other extensions. Provide a settings page, which stores data in Review Board-provided models (we even auto-generate the settings page for the extension by default). And more! A lot of this already exists in a private development branch, and it will be one of our primary focuses as soon as 1.0 goes out. In time, we’ll add a new section to the Review Board website where developers can list their extensions for download and for sale. Administrators will be able to browse and search for extensions directly from the administration UI and install them without having to even open a terminal (in most cases). We’re hoping this will solve a lot of in-house integration issues. For example, many companies have custom sandbox architectures, bug trackers, and statistics software which they’ll now be able to tie in with Review Board. Policy Customization We’ve found that a lot of companies have very specific ways they want to handle policy and access restrictions. For example, many companies want to limit who can see certain parts of a repository (and therefore certain diffs), or want to allow anybody to create review groups, or want to disallow people from joining review groups. Some also want to dictate what constitutes approval for submitting a change. We’re looking into the various requests and attempting to come up with a policy model that is flexible enough to handle these needs. One of the ideas is to provide some basic level of access control on a per-repository, per-path, and per-group basis. We’d then piggy-back on the extension framework to allow for more specific policy control. The advantage is that developers could write their own policy rules that interface with some part of their company’s infrastructure. If people have any input on this, we’d love to hear it. [Less]

A last-minute regression was found in our beta 1 release due to some API changes made in jQuery. We've fixed these issues and released beta 2, which all beta 1 users will need to upgrade to. We don't anticipate further showstopper regressions in ... [More] beta 2 (knock on wood), but if there are, please e-mail the mailing list and file a bug and we'll take care of it! [Less]

Along with the Review Board 1.0 beta 1 release, we're also announcing a new package called RBTools, which had its first release tonight. RBTools is the new home of post-review, and will in time contain new useful scripts for use with Review ... [More] Board. No longer do users have to grab the latest version of post-review from our source trees. We'll be providing formal releases from now on. To... [Less]