As the number of contributions grow, reviewer bandwidth becomes a bottleneck; and maintainers are always asking for more help. However,
ultimately maintainers must at least Ack every patch that goes in; so if you're not a maintainer, how can you contribute? Why should anyone care about your opinion?
This talk will try to lay out some advice and guidelines for non-maintainers, for how they can do code review in a way which will effectively reduce the load on maintainers when they do come to review a patch.
13. Necessary to accomplish goals?
• Is it clear what the goals are?
• Do we need to make a change, or can the goals be met with existing
functionality?
15. Architecture / Interface
• Is this the best way to solve the problem?
• Is this the right part of the code to modify?
• Is this the right level of abstraction?
• Is the interface general enough? Too general? Forward
compatible?
17. Functionality
• Does it do what it’s trying to do?
• Is it doing it in the most efficient way?
• Does it handle all the corner / error cases correctly?
19. Maintainability / robustness
• Is the code clear? Appropriately commented?
• Does it duplicate another piece of code?
• Does the code make hidden assumptions?
• Does it introduce sections which need to be kept “in sync” with other
sections?
• Are there other “traps” someone modifying this code might fall into?
20. Style
• Comments carriage returns, “snuggly braces”, &c
• See CODING_STYLE and tools/libxl/CODING_STYLE
• No extraneous whitespace changes
21. Patch
• Informative one-line changelog
• Full changelog
• Motivation described
• All important technical changes mentioned
• Changes since previous revision listed
• Reviewed-by’s and Acked-by’s dropped if appropriate
22. Patch: Audiences
• Reviewers trying to figure out what the patch does
• Someone scanning for patches important to them
• Archaeologists trying to figure out how the code got this way
23. Series
• Broken down appropriately?
• No regressions in the middle of the series
24. Reviewing tips
• Code follows data: Look at the data structures first
• Three ways to look at a patch
• Look at the patch itself (emacs / vim ‘diff mode’)
• Look at the patched file
• Graphical diff (i.e., meld)