Reviewing for Non-MaintainersGeorge Dunlap

Maintainers would love to have more help reviewing

…but many people don't know where to start

Absolutely perfect

Ready to be checked in

Not so ready

Goal: Help move a patch closer to being

ready to be checked in

But: “First, do no harm”

Not so helpful: Giving feedback the maintainer has

to contradict

Not so helpful: Beat up the new guy

Not so helpful: Looking for things to criticize

Helpful: Helping get the patch checked in

Necessary?

Architecture Interface

Effective Efficient All Cases Correct

Robust / Maintainable Coding Style Patch / Series

Necessary?

Architecture Interface

Effective Efficient All Cases Correct

Robust / Maintainable Coding Style Patch / Series

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?

Necessary?

Architecture Interface

Effective Efficient All Cases Correct

Robust / Maintainable Coding Style Patch / Series

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?

Necessary?

Architecture Interface

Effective Efficient All Cases Correct

Robust / Maintainable Coding Style Patch / Series

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?

Necessary?

Architecture Interface

Effective Efficient All Cases Correct

Robust / Maintainable Coding Style Patch / Series

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?

Style

• Comments carriage returns, “snuggly braces”, &c

• See CODING_STYLE and tools/libxl/CODING_STYLE

• No extraneous whitespace changes

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

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

Series

• Broken down appropriately?

• No regressions in the middle of the series

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)

Necessary?

Architecture Interface

Effective Efficient All Cases Correct

Robust / Maintainable Coding Style Patch / Series