Lines Matching refs:review

80 When making a patch for review, the goal is to make it as easy for the reviewer
123 .. _code review:
128 LLVM has a code review policy. Code review is one way to increase the quality of
142    all necessary review-related changes.
144 #. Code review can be an iterative process, which continues until the patch is
145    ready to be committed. Specifically, once a patch is sent out for review, it
150 larger features. Accepted ways to speed up review times for your patches are:
165 reviewees. If someone is kind enough to review your code, you should return the
166 favor for someone else.  Note that anyone is welcome to review and give feedback
169 There is a web based code review tool that can optionally be used
179 of code review plus post-commit review for trusted maintainers.  Having both is
182 review when they are confident they are right.
186 someone else will review it, allowing the patch to go unreviewed.  To solve this
195 review a piece of code, and we welcome code review from anyone who is
286 you follow these guidelines to help review, search in logs, email formatting
317   review or the mailing list.
390 In any case, your changes are still subject to `code review`_ (either before or
392 encouraged to review other peoples' patches as well, but you aren't required
438    extremely difficult to `code review`_.
464   (into a logical progression), simplifies code review and reduces the chance
470   "obvious" and can be committed without review.  Once the new API is in place
484 progression of code review, etc.). When doing so, it is important to retain
599   developers to validate assumptions, understand constraints and review code