We're proud to announce that we've released an initial version of the PDF Review extension. This extension allows viewing PDF attachments directly in your browser, and you can add comments on the content.
Review Board has been a fantastic tool for software developers for many years now, but over time, we've seen people try to use it for reviewing things beyond code. We've therefore been working to make Review Board useful to a wider audience beyond just developers.
Lately, we've been working toward the first part of this, a Review Board extension to enable peer review of PDF documents. We'll be holding a private beta of this extension pretty soon, and are opening up a sign-up form for those who are interested in giving it a try and giving us feedback.
In order to help fund the Review Board project, we plan to make this a paid extension (but free for open source or educational use). In exchange for your comments and feedback, participants in this beta will be offered a discount off the list price once we hit 1.0.
If you'd like to participate, please fill out the signup form and we'll be in touch.
Yesterday, we released Review Board 1.6.11, which required the new Django 1.3.2 security release. Unfortunately, as some users have noticed, Django 1.3.2 breaks Python 2.4 compatibility. We have filed a bug against Django, but in the meantime, if you're using Python 2.4, you may need to downgrade back to Django 1.3.1.
To downgrade, first locate the Django-1.3.2*.egg directory in your Python path. Delete that, and then install 1.3.1 by doing:
$ sudo easy_install Django==1.3.1
We are hoping this will be addressed soon, at which point we'll update our 1.6.11 package with a hotfix that requires the new version.
As previously mentioned, GitHub is transitioning to a new API and will be soon deprecating the version that Review Board speaks. We've been hard at work on this move (which brings with it a better repository configuration experience and the groundwork for tighter integration with GitHub and other services).
In the meantime, new users have been unable to link with private GitHub repositories, since GitHub no longer supplies the required API Token anywhere on the account page.
But good news! There is a workaround. If you have curl installed (common on Linux), you can request your API token by doing the following:
Enter your password when prompted. The result should show you your API token, which you can paste right into your repository configuration page.
We'll be sending out a release soon that will make it easier to get your API token when configuring the repository, followed by a new release with the GitHub API v3 additions in the following week or two. We want to make sure it's rock-solid first.
If you have any questions, we're always available on our mailing list.
GitHub has recently announced that they will soon be removing their older version 1.0 and 2.0 APIs, in favor of the newer version 3 API. This is scheduled to take place on May 1st, 2012.
Some users have already noticed that they have removed the API Token field, meaning that new GitHub Private and Private Organization accounts can't be accessed by Review Board today. We are in contact with GitHub and I'm hoping we'll have a solution to that.
Review Board uses the version 2.0 API to fetch files from GitHub, meaning that any installations using GitHub will stop working on May 1st. We are hard at work on moving to the version 3.0 API, and will have an update as soon as we can verify things are working properly. This will be Review Board 1.6.6.
There will be some manual steps required to get your GitHub repositories working again in 1.6.6. It will involve editing the repository entry, re-selecting GitHub, and authorizing an account. This will fetch the new OAuth2 API tokens from GitHub. Once you've done this, your repository will work again.
Further details will be provided as soon as we have a release.
Review Board 1.5.x users will need to upgrade to 1.6.6 in order to use their GitHub repositories.
Please contact our mailing list if you have any questions or concerns.
Those who have upgraded to Review Board 1.6.0 have no doubt noticed some problems with a few of the counters on the side of the Dashboard. Several may be set to 0, or in the negatives. This is an annoying bug, and many have reported it to us.
Don't worry, though, we were prepared for such things! You can reset your counters by typing:
rb-site manage /path/to/site fixreviewcounts
The counters should fix themselves the next time you're signed on. Now, any users who haven't logged in since the upgrade may find themselves hitting this bug again. Just re-run the same command and it'll solve it.
The upcoming 1.6.1 release will fix the bug and will perform a counter reset on your install. This should take care of it for everybody. You can expect that this weekend.
Those paying close attention may have noticed we haven't released Review Board 1.6 yet. And you may have wondered what's holding the release up. Well, there are two main things.
First, some of our users have hit problems upgrading to Review Board 1.6 RC2 from previous 1.6 betas. This seems to be limited to some subset of our users, and it's not clear whether it's a bug on our end or not, but I want to understand the circumstances surrounding this problem before we perform the actual release.
Second, the 1.6 manual isn't finished yet. We try to fully update the manual before the release, but this does inevitably delay things. We're working on getting someone who can in the future help out on documentation updates, in order to speed up the releases.
Once we're satisfied with the above items, we'll do a release. In the meantime, if you're looking to start using 1.6 sooner, you certainly can! The RC 2 release is largely what we're shipping in 1.6, excluding a couple of small fixes. However, please do a test upgrade on a copy of the database to ensure you don't run into the problem above. And if you do run into it, let us know! More data will help us to solve this faster.
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 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'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 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 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.
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 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.
We at Review Board are pleased to announce that Clearvision has released the latest version of their UCM4SVN (Unified Change Management for Subversion) product with out-of-the-box support for Review Board. From their press release:
UCM4SVN is a lightweight process layer which sits above the open source configuration management tool Subversion and enables development teams to quickly and easily structure their code and work items.
UCM4SVN removes all of the complication within Subversion associated with branching, merging, release management, permission management, change management integration etc. by providing a single browser based interface.
The new integration with Review Board will allow developers, team leaders and project managers to perform code reviews as part of the natural but managed process instigated by UCM4SVN. The high level steps are as follows;
Via UCM4SVN a team leader assigns development ‘activities’ which either originate from one of the integrated change management tools (IBM Rational ClearQuest, Atlassian Jira, Trac) or as a UCM4SVN created activity;
Via UCM4SVN the developer accepts the activity and UCM4SVN performs a Subversion checkout;
The developer uses their preferred Subversion IDE (Tortoise, Eclipse, command line) etc. to work on the change set or file for the activity and eventually completes the work and performs a final SVN commit;
The developer, via UCM4SVN chooses to perform a ‘Close’ or ‘Deliver’ action and integrate the activity of changes into a common integration branch;
The act of ‘Close’ or ‘Deliver’ automatically creates a ‘Review Board’ request ticket for the team member acting as a reviewer;
The reviewer, via UCM4SVN, can decide to perform a review by selecting the ticket. Such action automatically opens Review Board and from this point Review Board manages the review process and stores all review comments;
The interaction between Review Board and UCM4SVN is most valuable when a reviewer decides to fail a review. Under these circumstances, a UCM4SVN change request is automatically created and assigned to the original code developer to ensure the code changes are implemented;
UCM4SVN manages the entire process to ensure the original activity and the code change requests from Review Board are implemented into the final integration branch.
Through the integration between UCM4SVN and Review Board the reviewer’s comments and requests to improve the quality of code are never forgotten or misplaced, a full audit trail is clearly recorded.
The natural development process managed by UCM4SVN is strong and agile enough for companies of all sizes.
Clearvision initially considered developing their own code review tool however, after researching the market and evaluating a number of similar products, realised the Review Board product was an ideal fit and matched Clearvision’s goal of producing simple but effective applications.
Clearvision would like to give special thanks to all those involved in Review Board.
Clearvision provide Subversion training, subversion consulting, subversion support and a range of subversion products including integrations between ClearQuest, Jira, Trac, Subversion, Git and a variety of migration tools. UCM4SVN will shortly be extended to provide Application lifecycle Management for the open source configuration management product Git.
We've been fortunate enough to participate once again in the Google Summer of Code. This is an opportunity for students from around the world to work on interesting open source projects. This is our second year participating. Last year's efforts resulted in the upcoming Move Detection in the Diff Viewer, whitespace display toggling, Policy rule support (coming in probably 1.7), WebHooks (coming in 1.6), and Eclipse IDE integration.
This year we've selected three students with very exciting proposals:
Distributed Version Control System support to allow for reviewing patch sets and checking remote branch status.
Identifying repeated changes in a diff and summarizing or collapsing them, making it easier to review code where a function or variable has been renamed or changed in a consistent way throughout several files.
Work on the Extensions branch to help get our in-development Extensions support into better shape for a release.
A Linux installer making it easier to install Review Board on a variety of Linux distributions and keep it up-to-date.
We'd like to thank everyone who submitted a proposal this year, and we'd especially like to thank Google for once again accepting us into Summer of Code! Finally, we'd like to welcome our students into the project this year. It should be a great Summer.
We had the opportunity this year to participate in the Google Summer of Code, a program that pays college/university students to work on open source projects for the Summer. While we've mentored students in the past for other projects, this was our first year as an actual organization accepted into the program. And we can't wait for next year.
We had three students this year, Eduardo Felipe Castegnaro, Helder Ribeiro, and Markus Knittig. They worked on several awesome features, many of which are making it soon into the upcoming Review Board 1.1 development releases.
Eduardo Felipe Castegnaro
Eduardo worked on three main features: Improved whitespace detection/handling in the diff viewer, move detection, and policy support.
The new whitespace detection/handling feature gives reviewers the ability to dynamically show or hide lines that contain only whitespace changes. If a diff contains many lines that have, say, trailing whitespace removed, those lines can be hidden in order to simplify the review process. This feature is in today for the upcoming 1.1 alpha 1 release.
The move detection shows when a block of code in a diff has moved within the file, instead of just showing adds/deletes. Indicators beside the code show that the lines have moved, where they moved to or from, and, when clicked, will jump to the original or new location. This feature is scheduled for the 1.1 alpha 2 release.
The Policy support change is designed to give organizations more control over the rules governing their review process. It will be used in a future release to allow these organizations to enforce, for example, that a change can only be submitted if three senior people sign off on the change. There's still much that needs to be done for this work, and it won't be making it into the 1.1 release, but it's tremendous progress for this much-awaited feature.
Helder worked on support for Web Hooks and some infrastructure changes needed to support it.
Web Hooks allow organizations to set up scripts outside of Review Board that will be notified when a review request has been published or updated and when a review or reply has been posted. These could be used to, for example, update the bug reports associated with the review request, providing a link to the review request. Web Hooks are scheduled for the 1.1 release.
Much of Helder's work has been to get our code set up in such a way where both the Web Hooks and existing e-mail support can be based on the same signals. It's also done so that more notification mechanisms can be added in the future, which wasn't really easy and clean before. Helder also worked on various other little fixes throughout the code.
Markus worked on Eclipse integration for Review Board. This support will make it possible to manage review requests directly from within Eclipse. This work is a bit separate from the main Review Board codebase, and will be continuing on his eReviewBoard repository on GitHub.
This year was great, and we're certainly looking forward to participating again next year. Over the course of the Summer, we've learned what works, and what doesn't, and will be taking this knowledge into our next year in order to refine our processes and make the Summer of Code a great experience for everyone involved.
We'd like to publicly thank all of our students for working with us this year and producing such awesome work. We've sent special Review Board Summer of Code 2009 t-shirts to everyone involved, and hope they'll all continue to work with us on the project in the future.
Today, we finished a migration of the codebase from Google Code's SVN repository to Git repository hosted on GitHub.
Git is a distributed version control system gaining popularity in many companies and open source projects. We've been using it for Review Board development for quite some time, pushing changes to SVN once they're ready for the release. We felt moving to it fully was a natural next step.
Moving to Git has many advantages. We can make changes public before they're ready for inclusion by putting them on development branches. Users can play with the branches, easily merge between them, and even contribute to changes that are in-progress. Companies can maintain forks of the Review Board codebase with their own customizations and still keep them in sync without nearly as much effort as with SVN.
Contributors who have supplied patches to Review Board that are still pending will need to move their patches over to Git. An e-mail will be sent out to all contributors with pending patches with some instructions on this.
If you're unfamiliar with Git, take a look at GitHub's guides on using Git and GitHub.
Our project's Review Board server has been updated with the new repositories, "Review Board" and "RBTools." There's also a new "RBTools" review group, for changes against RBTools.
Tonight, we had some issues with the DNS mapping for the server hosting Djblets SVN. While this is a temporary problem, we decided to take the opportunity to begin a migration of Djblets over to Git. This is part of a longer-term plan to move both Review Board and Djblets to Git, which will help with our own development and allow third parties to maintain custom versions of Review Board without getting horribly out of sync with us.
If you're using Review Board and Djblets from official releases, you won't have to do anything. However, if you're currently using or developing against Review Board or Djblets SVN, you'll have to make some changes.
First, Djblets has new home on GitHub. To do a checkout of Djblets, you can type:
Second, you'll need to make some changes to your Review Board checkout in order to get things working again with the development server. We've removed the reviewboard/djblets and reviewboard/htdocs/media/djblets directories, which previously performed a checkout of the proper directories in Djblets To make things work again, do the following:
Install a build of Djblets (run python setup.py install in the Djblets checkout) or install it for development usage (python setup.py develop).
Make a symlink to the Djblets media directory in reviewboard/htdocs/media by typing:
$ cd reviewboard/htdocs/media
$ ln -s /path/to/djblets/djblets/media djblets
Once you've made these changes, you should be able to build and test Review Board again. If you need any help, contact us on our mailing list.
This year, Review Board has been accepted as a mentoring organization in Google's Summer of Code. This will give students an opportunity to contribute to Review Board and to get paid to do so, and it should result in some awesome features added in the next version of Review Board.
Students who would like to participate should look at our ideas page for possible projects and our Summer of Code Information page for some helpful links and details on participating.
We've also decided to continue offering Review Board hosting for projects participating in Summer of Code, even ones that aren't related to Review Board. This can help mentors to review students' code, keep track of what was done, and to introduce students to good code review practices.
Review Board has been around for a couple of years now, and the UI really hasn't changed much. The initial UI we wrote worked well enough, but had a number of usability problems we were all too aware of. We knew we needed to address these for the 1.0 release.
In an effort to streamline the code review process, we've made several key changes.
The comment/review dialog has been split up and simplified. The old dialog was confusing to many users for a number of reasons. Mainly, it tried to do too much by handling not only commenting on a diff line or screenshot but the reviews as well.
People often tried using the old dialog to reply to existing comments, which led to brand new reviews instead of replies. This was largely due to the way we represented comments on the old dialog.
Now we have a simple comment dialog for both the diff viewer and screenshot pages. The green portion representing the new draft comment provides a single text area for the comment, and Save and Cancel buttons. To the left is a list of existing comments for that region (if any). Each item contains "View" and "Reply" buttons. Clicking these will jump to the reviews page, and in the case of "Reply," a new comment will be added below the comment being replied to on the reviews page. This will hopefully make replying more straightforward. We have some further improvements we'll make in this area in the future.
The review portion of the dialog is now its own entity. When clicking on "Review" on the review request details box, or when clicking "Edit Review" on the new draft banner (which is docked to the top of a review request page when there's a pending review), a modal box will pop up containing the review.
This new box is a vast improvement over the old review dialog. Like actual reviews, the screenshot and diff fragments are displayed inline, and progressively loaded. Users can make changes to existing comments they've made. The review can be saved, published, or discarded straight from there, or from the banner itself.
No more lost comments
It's harder to lose comments now. When there's a pending comment on a page and the user attempts to move away from the page, a confirmation dialog will appear. This currently happens on the diff viewer and screenshot dialogs only. The functionality will be added in a later change to reviews and the review form.
Feedback and comment previews
There's more feedback now when making changes. When saving or deleting a comment, little bubbles briefly float up near the comment flag or region and let the user know what just happened.
The selected region of the diff viewer used to be indicated by a little arrow in the left-hand column. This was sometimes hard to notice. We now make the border around that region more bold, making it quite clear where you are in the diff viewer.
Hovering over a comment flag or a comment region now shows a little tooltip with the comments. It's very brief. No author information is shown, just the text, but clicking the area provides that additional information.
We provide slightly better error feedback now. The error banners at the top of the page now contain any debug information, such as a backtrace, when something goes wrong. In DEBUG=True installs, this information is very valuable. This certainly makes debugging Review Board itself much easier.
Better action placement
Review request actions ("Set Submitted", "Add Screenshot", etc.) have been moved to the top of the review request box where they're more easily seen. "Set Submitted," "Discard" and "Delete" are no longer top-level actions. They now exist in a "Close" drop-down menu. This saves space and groups them together under one concept -- you're in some way closing a review request out.
More descriptive dialogs
We're working to add some better help to the dialogs. The Upload Diff dialog, for instance, now has descriptions below each field. In the future, we'll add better inline helping throughout the product.
Better browser compatibility
We have much better browser compatibility now. The new UI should work quite well on IE6/7/8, Firefox, Opera, Safari, and Konqueror.
It's very important to clear your server-side cache when upgrading Review Board, or some things just won't work. If using memcached, restart the service.
You may also need to tell your users to clear their browser cache if they run into problems.
Please let us know if there are major issues with this rewrite. It's been tested fairly heavily, but may still have unforeseen problems. As always, you can report bugs or post to the mailing list for help.
One of the major pain points of Review Board has been its installation methods. Users had to do a lot to get Review Board up and running initially. We've finally addressed this with new Python Egg packaging and a site installation wizard.
The major parts of installation basically boils down to two commands:
Django, the web framework Review Board is built upon, is approaching their 1.0 release and have released Django 1.0 alpha for download. In order to keep up with Django development, Review Board has required the Django Subversion development tree to run, requiring that users develop a basic understanding of Subversion and keeping their copy up-to-date.
With the new Django alpha release, we're now able to remove this extra burden. As of tonight, Review Board now requires Django 1.0 alpha or higher. Simply download the new release and install it. Of course, if you're currently using a Subversion checkout of Django, you can continue to use it.
The Django 1.0 release will bring us a step closer to our own 1.0. There's a few major features still planned, and lots of bug fixing. We'll have a roadmap up in the coming weeks detailing our plans. Stay tuned!