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 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 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:
In April 2010 Cleavision released version 2.2 of UCM4SVN which included an integration with the open source code review tool Review Board.
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 Ribeiro
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 Knittig
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.
Wrapping Up...
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.
This will create a reviewboard directory containing the codebase. To fetch new changes, make sure you're on the master branch and then pull the latest changes:
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.
