Jump to: navigation, search

Difference between revisions of "ReviewChecklist"

(Nova Review Checklist)
(Common Review Checklist)
Line 9: Line 9:
 
* '''a)''' If it's not installed by setup.py, but should be included in the tarball, be sure to add it to `MANIFEST.in`.
 
* '''a)''' If it's not installed by setup.py, but should be included in the tarball, be sure to add it to `MANIFEST.in`.
  
3. A single commit should be as small as is practicable while maintaining atomic functionality. If a commit message includes "and do this other thing", it should probably be split up.
+
3. A single commit should be as small as is practicable while maintaining atomic functionality. If a commit message includes "and do this other thing", it should probably be split up. For more details on this, see [[GitCommitMessages]].
  
 
= Nova Review Checklist =
 
= Nova Review Checklist =

Revision as of 22:25, 24 July 2013

This page includes a list of things that reviewers should keep in mind when reviewing patches to OpenStack projects. There are some items that are common across all projects and others that are specific to a project.

Common Review Checklist

1. The code should comply with everything in HACKING.

2. When adding a new file:

  • a) If it's not installed by setup.py, but should be included in the tarball, be sure to add it to `MANIFEST.in`.

3. A single commit should be as small as is practicable while maintaining atomic functionality. If a commit message includes "and do this other thing", it should probably be split up. For more details on this, see GitCommitMessages.

Nova Review Checklist

1. When adding a new file:

  1. Check common checklist items for adding new files.
  2. If you are adding a new script in the `bin/` directory, add it to `setup.py`.

2. When syncing from oslo:

  1. Ensure the proposed change has actually merged in oslo.
  2. It should provide some benefit, don't sync just to sync. Maybe it fixes a bug, or provides new functionality to be used. If providing new functionality it should have a dependent patch lined up to use that functionality.

3. For API changes:

  1. If an API sample test template changes, ensure the doc samples are also updated.

Notes for Non-Core Developers

  • When you are reviewing, you may notice a review that has several +1's from other reviewers, passes the functional tests, etc. but the code still has not been merged. As only core developers can approve code for merging, you can help things along by getting a core developer's attention and letting them know there is a review with lots of positive reviews and needs final approval.