Patch Review Process

Submission review

• Is the patch in the standard form?
• Does it apply cleanly to the current CVS HEAD?
• Does it include reasonable tests, docs, etc?

Usability review

Read what the patch is supposed to do, and consider:

• Does the patch actually implement that?
• Do we want that?
• Do we already have it?
• Does it follow SQL spec, or the community-agreed behavior?
• Are there dangers?
• Have all the bases been covered?

Feature test

Apply the patch, compile it and test:

• Does the feature work as advertised?
• Are there corner cases the author has failed to consider?

Performance review

• Does the patch slow down simple tests?
• If it claims to improve performance, does it?
• Does it slow down other things?

Coding review

Read the changes to the code in detail and consider:

• Does it follow the project coding guidelines?
• Are there portability issues?
• Will it work on Windows/BSD etc?
• Are the comments sufficient and accurate?
• Does it do what it says, correctly?
• Does it produce compiler warnings?
• Can you make it crash?

Architecture review

Consider the changes to the code in the context of the project as a whole:

• Is everything done in a way that fits together coherently with other features/modules?
• Are there interdependencies than can cause problems?

Review review

• Did the reviewer cover all the things that kind of reviewer is supposed to do?

Lifted from here :PostgreSQL

[PostgreSQL] http://wiki.postgresql.org/wiki/Reviewing_a_Patch