Difference between revisions of "Code Review Tool"
m (→post-review: link to documentation) |
m (we use 1.5.2 so link to 1.5 docu rather than 1.0) |
||
Line 8: | Line 8: | ||
Use of this system is limited to developers who have executed a [http://lecs.opensource.secondlife.com/SLVcontribution_agmt.pdf Second Life Viewer Contribution Agreement]. Any changes or comments posted to the tool are Contributions as defined by that Agreement. | Use of this system is limited to developers who have executed a [http://lecs.opensource.secondlife.com/SLVcontribution_agmt.pdf Second Life Viewer Contribution Agreement]. Any changes or comments posted to the tool are Contributions as defined by that Agreement. | ||
For complete documentation, see [http://www.reviewboard.org/docs/manual/1. | For complete documentation, see [http://www.reviewboard.org/docs/manual/1.5/users/ the ReviewBoard User Manual]. | ||
==Logging In== | ==Logging In== | ||
Line 25: | Line 25: | ||
[[Image:Reviewboard.mydashboard.png]] | [[Image:Reviewboard.mydashboard.png]] | ||
The Dashboard displays reviews and lets you select the ones of interest to you. See the [http://www.reviewboard.org/docs/manual/1. | The Dashboard displays reviews and lets you select the ones of interest to you. See the [http://www.reviewboard.org/docs/manual/1.5/users/navigating/dashboard/ full Dashboard documentation]. | ||
==Post Code To Be Reviewed== | ==Post Code To Be Reviewed== |
Revision as of 09:31, 23 March 2011
- 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).
Reviewing
To see the changes in a review request, select View Diff:
Whenever possible, comment by selecting specific lines of code; click and drag on the line numbers:
Enter your comment in the floater (remember to direct comments to the code, and not the coder), and press Save to record the comment:
When you've made your specific comments, you can edit the review as a whole and add any general comments by selecting Edit Review:
- Click the Ship It checkbox if your overall opinion is that he change is ready to be integrated; leave it unchecked if your comments suggest additional changes that should be made.
When your review is ready to be read by others (including being forwarded to the requester and the mailing list), select Publish Review; until you Publish it, your review cannot be found.
You can also Save Review to preserve what you have done so far, but this does not make it visible.