Lines Matching full:patch

33 likely-community-consensus requirements (as apply to all patch approvals) can
35 uncertainty, a patch should be reviewed prior to being committed.
37 Please note that the developer responsible for a patch is also
49 the patch to be :ref:`reverted <revert_policy>`.
55 the patch promptly. Developers often disagree, and erring on the side of the
57 code in the tree. This does not indicate any fault from the patch author,
59 Reverting a patch ensures that design discussions can happen without blocking
60 other development; it's entirely possible the patch will end up being reapplied
63 Before being recommitted, the patch generally should undergo further review.
76 original change was committed, it may be better to create a new patch to
77 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.
115 All comments by reviewers should be acknowledged by the patch author. It is
117 revision of the patch unless the author and/or other reviewers can articulate a
118 good reason to do otherwise (and then the reviewers must agree). If a new patch
120 that when providing the updated patch. When using the web-based code-review
139 the author can make all of the changes at once. If a patch will require
142 possible. This allows the patch author and reviewers to make the most efficient
147 LGTM - How a Patch Is Accepted
150 A patch is approved to be committed when a reviewer accepts it, and this is
161 that all other reviewers will almost surely be satisfied with the patch being
175 the patch (which literally means submitting a comment on the patch with the
179 If it is likely that others will want to review a recently-posted patch,
183 quickly, a patch author may also elect to wait before committing (and this is
190 providing an overall approval for a patch, is to be reasonably sure that such
195 Every patch should be reviewed by at least one technical expert in the areas of
201 Reviewers may request certain aspects of a patch to be broken out into separate
202 patches for independent review. Reviewers may also accept a patch
203 conditioned on the author providing a follow-up patch addressing some
204 particular issue or concern (although no committed patch should leave the
205 project in a broken state). Moreover, reviewers can accept a patch conditioned on
212 If you review a patch, but don't intend for the review process to block on your
214 committing a patch until all reviewers are satisfied, and if you don't intend
215 to look at the patch again in a timely fashion, please communicate that fact in
246 If you are an expert in an area of the compiler affected by a proposed patch,
248 maintainer, and no other experts are reviewing a patch, you must either help
249 arrange for an expert to review the patch or review it yourself.
259 * Ping the patch. If it is urgent, provide reasons why it is important to you to
260   get this patch landed and ping it every couple of days. If it is
265 * Split your patch into multiple smaller patches that build on each other. The
266   smaller your patch is, the higher the probability that somebody will take a quick
268   the title of each patch in the series, so it is clear that there is an order
274 on a patch, but approval of patches should be consistent with the policy above.