Design/Code Review Guidelines

Design Reviews Should Check For:

How-to design wiki for Sqoop2.

Use the above as a guideline to ask specific questions about the design such as the 

• Scope of this feature, what it does intend to change and what it does not. 
• What the relevant components in Sqoop that will be affected by this change?
• It might be good to help them break down the design if it is too large and will extend more than few weeks to get the first cut
• Ask them if any of the design decisions were based on some benchmarks/testing if performance is stated as a goal
• Make sure they have done even research to leverage existing utilities/libraries instead of re-inventing the wheel again

Code Reviews Should Check For:

• Is the code change consistent with the proposed design?
• Is the new feature or bug fix well covered by unit tests?
• Is the new code sufficiently documented (i.e. code comments and wiki where needed) ? 
• If the feature is user facing, the user documentation must be updated. 
• Does the code break backward compatibility? (For example, adding abstract methods to class used by connectors)
• Are there new dependencies? Are there new dependencies on non-open-source components?
• Is the placement of objects in packages consistent with the rest of the project?
• Does the patch apply? Unit and integration tests pass?

 More in-depth review checklist per sqoop component.