summaryrefslogtreecommitdiffstats
path: root/llvm/docs/DeveloperPolicy.rst
diff options
context:
space:
mode:
authorManuel Klimek <klimek@google.com>2013-08-26 07:29:08 +0000
committerManuel Klimek <klimek@google.com>2013-08-26 07:29:08 +0000
commitaeb642276ea0d5993ade0364b02127e6c92759b1 (patch)
treeefce484835018aef92699e524716b5091e5d22be /llvm/docs/DeveloperPolicy.rst
parentf1947537a09cefdb643ab170da023770d171d0bd (diff)
downloadbcm5719-llvm-aeb642276ea0d5993ade0364b02127e6c92759b1.tar.gz
bcm5719-llvm-aeb642276ea0d5993ade0364b02127e6c92759b1.zip
Include a clearer policy about what's ok/nok to speed up code reviews.
llvm-svn: 189210
Diffstat (limited to 'llvm/docs/DeveloperPolicy.rst')
-rw-r--r--llvm/docs/DeveloperPolicy.rst19
1 files changed, 18 insertions, 1 deletions
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
index 0655559cee1..0f2136aa2ed 100644
--- a/llvm/docs/DeveloperPolicy.rst
+++ b/llvm/docs/DeveloperPolicy.rst
@@ -128,7 +128,24 @@ software. We generally follow these policies:
all necessary review-related changes.
#. Code review can be an iterative process, which continues until the patch is
- ready to be committed.
+ ready to be committed. Specifically, once a patch is sent out for review, it
+ needs an explicit "looks good" before it is submitted. Do not assume silent
+ approval, or request active objections to the patch with a deadline.
+
+Sometimes code reviews will take longer than you would hope for, especially for
+larger features. Accepted ways to speed up review times for your patches are:
+
+* Review other people's patches. If you help out, everybody will be more
+ willing to do the same for you; goodwill is our currency.
+* Ping the patch. If it is urgent, provide reasons why it is important to you to
+ get this patch landed and ping it every couple of days. If it is
+ not urgent, the common courtesy ping rate is one week. Remember that you're
+ asking for valuable time from other professional developers.
+* Ask for help on IRC. Developers on IRC will be able to either help you
+ directly, or tell you who might be a good reviewer.
+* Split your patch into multiple smaller patches that build on each other. The
+ smaller your patch, the higher the probability that somebody will take a quick
+ look at it.
Developers should participate in code reviews as both reviewers and
reviewees. If someone is kind enough to review your code, you should return the
OpenPOWER on IntegriCloud