Lines Matching refs:review

9 help make our task of contribution review easier and your change is
25    * - Be prepared to respond to review comments
26      - Code that doesn't pass review will not get merged. See :ref:`participating_in_code_review`
103 Make code motion patches easy to review
107 making the refactoring easier to review. Split up the series so that
284 Send patches inline so they are easy to reply to with review comments.
361 When reviewers don't know your goal at the start of their review, they
364 their review. A series where the goal is unclear also risks a higher
365 number of review-fix cycles because the reviewers haven't bought into
382 review on it anyway. Reasons for doing this include:
388    cases or work with all targets) but you want early review of a major
391 In general, since it's asking other people to do review work on a
397    of the patchset you're looking for review on, and why reviewers
417 All patches submitted to the QEMU project go through a code review
429 Some areas of code that are well maintained may review patches
434 Stay around to fix problems raised in code review
459 Pay attention to review comments
462 Someone took their time to review your work, and it pays to respect that
468 pointed out a potential issue during review, then even if your code
473 If you fix issues that are raised during review **resend the entire
528 Proper use of Reviewed-by: tags can aid review
555 review comments on an earlier version?), but often for less-maintained
572 Once your patch has had enough review on list, the maintainer for that
580 fixing minor typos pointed out during review, but will always add a
585 patch first had a positive review to when it finally lands in qemu.git;
593 Peer review only works if everyone chips in a bit of review time. If
595 patch backlog. A good goal is to try to review at least as many patches
598 review is weak because you are unfamiliar with the code.