Index: en_US.ISO8859-1/articles/committers-guide/article.xml =================================================================== --- en_US.ISO8859-1/articles/committers-guide/article.xml +++ en_US.ISO8859-1/articles/committers-guide/article.xml @@ -2302,6 +2302,81 @@ + + Pre-Commit Review + + Code review is one way to increase the quality of software. + The FreeBSD Project encourages all committers to follow these + guidelines: + + + All non-trivial changes should be reviewed before they + are committed to the repository. + + + + Reviews may be conducted by email, in + Bugzilla, in + Phabrictor, or by other + mechanism. Where possible, reviews should be public. + + + + The developer responsible for a code change is also + responsible for making all necessary review-related + changes. + + + + Code review can be an iterative process, which continues + until the patch is ready to be committed. Specifically, + once a patch is sent out for review, it should receive an + explicit “looks good” before it is committed. + + + + 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 mailing lists, IRC, etc. Others + may be able to either help you directly, or suggest a + 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 favor for someone else. Note + that anyone is welcome to review and give feedback on a patch, + but only people with an appropriate commit bit can approve + it. + + Commit Log Messages