diff options
author | Manuel Klimek <klimek@google.com> | 2013-08-26 07:29:08 +0000 |
---|---|---|
committer | Manuel Klimek <klimek@google.com> | 2013-08-26 07:29:08 +0000 |
commit | 4989188a40c4e9cd1016584960296d795e252a6c (patch) | |
tree | af52aae165b132f93cb5ebc1b6b32d631ce6606b /docs/DeveloperPolicy.rst | |
parent | 318f4e679b6293bf28eb288126846c4c650528be (diff) | |
download | external_llvm-4989188a40c4e9cd1016584960296d795e252a6c.zip external_llvm-4989188a40c4e9cd1016584960296d795e252a6c.tar.gz external_llvm-4989188a40c4e9cd1016584960296d795e252a6c.tar.bz2 |
Include a clearer policy about what's ok/nok to speed up code reviews.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189210 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/DeveloperPolicy.rst')
-rw-r--r-- | docs/DeveloperPolicy.rst | 19 |
1 files changed, 18 insertions, 1 deletions
diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst index 0655559..0f2136a 100644 --- a/docs/DeveloperPolicy.rst +++ b/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 |