) and Reviewboard (https://reviewboard.asterisk.org
) are both utilities that the Asterisk development community uses to help track and review code being written for Asterisk. Since both systems are used for posting patches, it is worth discussing when it is appropriate to use reviewboard and when not.
Here are the situations in which it is appropriate to post code to reviewboard:
- A committer has a patch that they would like to get some feedback on before merging into one of the main branches.
- A committer or bug marshal has requested a contributor to post their patch from Mantis on reviewboard to aid in the review process. This typically happens with complex code contributions where reviewboard can help aid in providing feedback.
We do encourage all interested parties to participate in the review process. However, aside from the cases mentioned above, we prefer that all code submissions first go through Mantis.
- It is acceptable for a committer to post patches to reviewboard before they are complete to get some feedback on the approach being taken. However, if the code is not yet ready to be merged, it must be documented as such. A review request with a patch proposed for merging should have documented testing and should not have blatant coding guidelines violations. Lack of these things is careless and shows disrespect for those reviewing your code.
The easiest way to post a patch to reviewboard is by using the post-review tool. We have post-review in our repotools svn repository.
* $ svn co http://svn.digium.com/svn/repotools
Essentially, post-review is a script that will take the output of "svn diff" and create a review request out of it for you. So, once you have a working copy with the changes you expect in the output of "svn diff", you just run the following command:
If it complains about not knowing which reviewboard server to use, add the server option:
* $ post-review --server=https://reviewboard.asterisk.org
I have one final note about an oddity with using post-review. If you maintain your code in a team branch, and the new code includes new files, there are some additional steps you must take to get post-review to behave properly.
You would start by getting your changes applied to a trunk working copy:
Then, apply the changes from your branch:
* $ svn merge .../trunk .../team/group/my_new_code
Now, the code is merged into your working copy. However, for a new file, subversion treats it as a copy of existing content and not new content, so new files don't show up in "svn diff" at this point. To get it to show up in the diff, use the following commands so svn treats it as new content and publishes it in the diff:
* $ svn revert my_new_file.c
* $ svn add my_new_file.c
Now, it should work, and you can run "post-review" as usual.
Most of the time, a patch on reviewboard will require multiple iterations before other sign off on it being ready to be merged. To update the diff for an existing review request, you can use post-review and the -r option. Apply the current version of the diff to a working copy as described above, and then run the following command:
* $ post-review -r <review request number>