Lines Matching refs:patch

31 likely-community-consensus requirements (as apply to all patch approvals) can
33 uncertainty, a patch should be reviewed prior to being committed.
35 Please note that the developer responsible for a patch is also
47 the patch to be :ref:`reverted <revert_policy>`.
53 the patch promptly. Developers often disagree, and erring on the side of the
55 code in the tree. This does not indicate any fault from the patch author,
57 Reverting a patch ensures that design discussions can happen without blocking
58 other development; it's entirely possible the patch will end up being reapplied
61 Before being recommitted, the patch generally should undergo further review.
74 original change was committed, it may be better to create a new patch to
75 address the issues than comment on the original commit. The original patch
101 Code review can be an iterative process, which continues until the patch is
102 ready to be committed. Specifically, once a patch is sent out for review, it
104 approval, or solicit objections to a patch with a deadline.
109 All comments by reviewers should be acknowledged by the patch author. It is
111 revision of the patch unless the author and/or other reviewers can articulate a
112 good reason to do otherwise (and then the reviewers must agree). If a new patch
114 that when providing the updated patch. When using the web-based code-review
128 the author can make all of the changes at once. If a patch will require
131 possible. This allows the patch author and reviewers to make the most efficient
137 A patch is approved to be committed when a reviewer accepts it, and this is
144 that all other reviewers will almost surely be satisfied with the patch being
152 the patch (which literally means submitting a comment on the patch with the
156 If it is likely that others will want to review a recently-posted patch,
160 quickly, a patch author may also elect to wait before committing (and this is
167 providing an overall approval for a patch, is to be reasonably sure that such
172 Every patch should be reviewed by at least one technical expert in the areas of
178 Reviewers may request certain aspects of a patch to be broken out into separate
179 patches for independent review. Reviewers may also accept a patch
180 conditioned on the author providing a follow-up patch addressing some
181 particular issue or concern (although no committed patch should leave the
182 project in a broken state). Moreover, reviewers can accept a patch conditioned on
189 If you review a patch, but don't intend for the review process to block on your
191 committing a patch until all reviewers are satisfied, and if you don't intend
192 to look at the patch again in a timely fashion, please communicate that fact in
223 If you are an expert in an area of the compiler affected by a proposed patch,
225 owner, and no other experts are reviewing a patch, you must either help arrange
226 for an expert to review the patch or review it yourself.
236 * Ping the patch. If it is urgent, provide reasons why it is important to you to
237   get this patch landed and ping it every couple of days. If it is
242 * Split your patch into multiple smaller patches that build on each other. The
243   smaller your patch is, the higher the probability that somebody will take a quick
245   the title of each patch in the series, so it is clear that there is an order
251 on a patch, but approval of patches should be consistent with the policy above.