Reviewing a Patch
From PostgreSQL Wiki
Many people feel that they're not qualified to do a full review of patches submitted to PostgreSQL. If you're not already a committer, that's technically true in at least that sense, and since the project is so large it's quite difficult to understand the whole code base. But review includes many different tasks, and even if you can't do all of them you can help the project by taking on the earlier phases.
If you can apply a patch and you can use the new feature, you're already qualified to start reviewing it.
The eventual committer will do their own review before the patch goes into the codebase. The task of a reviewer is to take off load from committers by catching simple problems. The reviewer's job is not to guarantee some level of quality, but just to report any problems they are able to find. That task is done if you think the patch is ready for in-depth review from a committer.
Phases a patch review might go through include:
Contents |
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?
