Code review is one way to increase the quality of software.
The following guidelines apply to commits to the
head (-CURRENT) branch of the
src repository. Other branches and the
ports and docs trees have
their own review policies, but these guidelines generally apply
to commits requiring review:
All non-trivial changes should be reviewed before they are committed to the repository.
Reviews may be conducted by email, in Bugzilla, in Phabricator, or by another 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. So long as it is explicit, this can take whatever form makes sense for the review method.
Timeouts are not a substitute for review.
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 are 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.
When making large changes, it is helpful to keep this in mind from the beginning of the effort as breaking large changes into smaller ones is often difficult after the fact.
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 while anyone is welcome to review and give feedback on a patch, only an appropriate subject-matter expert can approve a change. This will usually be a committer who works with the code in question on a regular basis.
In some cases, no subject-matter expert may be available. In those cases, a review by an experienced developer is sufficient when coupled with appropriate testing.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.