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.

1. Reviewing for Non-Maintainers
George Dunlap

2. Maintainers would love to have
more help reviewing

3. …but many people don't know
where to start

4. Absolutely
perfect
Ready to be
checked in
Not so
ready

5. Goal:
Help move a patch closer to being
ready to be checked in

6. But:
“First, do no harm”

7. Not so helpful:
Giving feedback the maintainer has
to contradict

8. Not so helpful:
Beat up the new guy

9. Not so helpful:
Looking for things to criticize

10. Helpful:
Helping get the patch checked in

11. Necessary?
Architecture Interface
Effective Efficient
All Cases
Correct
Robust /
Maintainable
Coding Style Patch / Series

12. Necessary?
Architecture Interface
Effective Efficient
All Cases
Correct
Robust /
Maintainable
Coding Style Patch / Series

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?

14. Necessary?
Architecture Interface
Effective Efficient
All Cases
Correct
Robust /
Maintainable
Coding Style Patch / Series

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?

16. Necessary?
Architecture Interface
Effective Efficient
All Cases
Correct
Robust /
Maintainable
Coding Style Patch / Series

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?

18. Necessary?
Architecture Interface
Effective Efficient
All Cases
Correct
Robust /
Maintainable
Coding Style Patch / Series

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)

25. Necessary?
Architecture Interface
Effective Efficient
All Cases
Correct
Robust /
Maintainable
Coding Style Patch / Series