Add documentation for reviewboard usage and guidelines.
authorRussell Bryant <russell@russellbryant.com>
Wed, 8 Apr 2009 19:59:21 +0000 (19:59 +0000)
committerRussell Bryant <russell@russellbryant.com>
Wed, 8 Apr 2009 19:59:21 +0000 (19:59 +0000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187179 65c4cc65-6c06-0410-ace0-fbb531ad65f3

include/asterisk/doxygen/reviewboard.h [new file with mode: 0644]
include/asterisk/doxyref.h

diff --git a/include/asterisk/doxygen/reviewboard.h b/include/asterisk/doxygen/reviewboard.h
new file mode 100644 (file)
index 0000000..57fa01b
--- /dev/null
@@ -0,0 +1,127 @@
+/*
+* Asterisk -- An open source telephony toolkit.
+*
+* Copyright (C) 1999 - 2009, Digium, Inc.
+*
+* See http://www.asterisk.org for more information about
+* the Asterisk project. Please do not directly contact
+* any of the maintainers of this project for assistance;
+* the project provides a web site, mailing lists and IRC
+* channels for your use.
+*
+* This program is free software, distributed under the terms of
+* the GNU General Public License Version 2. See the LICENSE file
+* at the top of the source tree.
+*/
+
+/*!
+* \file
+*/
+
+/*!
+ * \page Reviewboard Reviewboard Usage and Guidelines
+ *
+ * \AsteriskTrunkWarning
+ *
+ * <hr/>
+ *
+ * \section ReviewboardGuidelines Usage Guidelines
+ *
+ * Mantis (http://bugs.digium.com) and Reviewboard (http://reviewboard.digium.com)
+ * 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.
+ *
+ * \note 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 \b 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.
+ *
+ * <hr/>
+ *
+ * \section ReviewboardPosting Posting Code to Reviewboard
+ *
+ * \subsection postreview Using post-review
+ *
+ * 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.
+ *
+   \verbatim
+   $ svn co http://svn.digium.com/svn/repotools
+   \endverbatim
+ *
+ * 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:
+ *
+   \verbatim
+   $ post-review
+   \endverbatim
+ * 
+ * If it complains about not knowing which reviewboard server to use, add
+ * the server option:
+ * 
+   \verbatim
+   $ post-review --server=http://reviewboard.digium.com
+   \endverbatim
+ *
+ * \subsection postreviewnewfiles Dealing with New Files
+ * 
+ * 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:
+ * 
+   \verbatim
+   $ cd .../trunk
+   \endverbatim
+ * 
+ * Then, apply the changes from your branch:
+ * 
+   \verbatim
+   $ svn merge .../trunk .../team/group/my_new_code
+   \endverbatim
+ * 
+ * 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:
+ * 
+   \verbatim
+   $ svn revert my_new_file.c
+   $ svn add my_new_file.c
+   \endverbatim
+ * 
+ * Now, it should work, and you can run "post-review" as usual.
+ *
+ * \subsection postreviewupdate Updating Patch on Existing Review Request
+ *
+ * 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:
+ * 
+   \verbatim
+   $ post-review -r <review request number>
+   \endverbatim
+ */
index 6afe44c..e8ca6ec 100644 (file)
@@ -36,6 +36,7 @@
  * \arg \ref CommitMessages : Information on formatting and special tags for commit messages
  * \arg \ref ReleaseStatus : The current support level for various Asterisk releases
  * \arg \ref ReleasePolicies : Asterisk Release and Commit Policies
+ * \arg \ref Reviewboard : Reviewboard Usage and Guidelines
  * \arg \ref AstCREDITS : A Thank You to contributors (unfortunately out of date)
  *
  * \section apisandinterfaces Asterisk APIs and Interfaces