Code Review Tool
- Given enough eyeballs, all bugs are shallow
- - Linus' Law, according to Eric S. Raymond
Linden Lab maintains an instance of the ReviewBoard code review tool at codereview.secondlife.com to be used for reviewing any proposed changes to any of our open source projects.
Use of this system is limited to developers who have executed a Second Life Viewer Contribution Agreement. Any changes or comments posted to the tool are Contributions as defined by that Agreement.
For complete documentation, see the ReviewBoard User Manual.
Logging In
Access to the system requires that you set up an account, which you can do on your own from the login page or by going directly to the account registration page.
When creating your account:
- Please use the same user id that you use for Jira.
- Use the same email address that you use for the opensource-dev mailing list (if you do not, then the notices of reviews you post and comments you make will not be successfully sent to the list).
- Select the 'Viewer' group
You may find yourself on the account creation screen again after you log in, if so, just follow the My Dashboard link:
The Dashboard displays reviews and lets you select the ones of interest to you. See the full Dashboard documentation.
Post Code To Be Reviewed
Prepare your change in a local working hg repository. It will be easier to keep track of outstanding reviews if you commit your change to that repository before posting it for review.
Once you have a local copy of the change, there are two ways to post it for review:
- manually upload patch using the web page interface
- post-review command line tool
Either way, you must Publish Your Review before any other users will be able to see it or comment on it.
manually upload patch
To create a patch file that shows your change, execute the following command from the top level of your repository:
hg diff -c commit > PATCH
where commit is the revision identifier for your change (if you have not made any other changes, this can just be tip). If you have not committed your change, you can leave off the -c commit, but this is not recommended.
Follow the New Review Request link to begin manually creating a review:
This takes you to the form that lets you upload your patch:
Select the repository from which you forked/cloned your working repository (making the wrong choice here increases the chance that the patch will not apply cleanly), and upload the PATCH file in the Diff field. You usually will not need the Parent Diff upload field, and can leave it empty. Then push the Create Review Request button to upload your patch and create a Draft Review:
Fill out each of the fields:
- Summary
- The first line of your commit message should be perfect for this.
- Groups
- Enter viewer (it will auto-complete)
- Bugs
- The identifier for the Jira issue this relates to (this becomes a link to the issue, but you just need to provide the key)
- Description
- Describe the fix, not the issue. Explain the changes made (for example, why the new code is better than the old code) and how you arrived at that solution.
- Testing Done
- Optional, but very nice if you can provide useful information here.
You must Publish Your Review
post-review
There is a command line tool called post-review, but it is not very mature and whether or not it works can depend on how you created your mercurial repository. I plan to work on improving this asap - Oz
Publish Your Review
Until you Publish your review, only you can see it. When you do publish it, a notice is sent to the opensource-dev mailing list (and, optionally to any People whose codereview accounts you have selected).
Commenting
Whenever possible, comment by selecting lines in the file and entering a comment. It makes it much more specific than if you post a general comment.