Am 29.08.2012 23:55, schrieb Sumana Harihareswara:
Version with helpful links: https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews
- Write small commits.
It's easier for other people to review small changes that only change one thing. We'd rather see five small commits than one big one.
- Respond to test failures and feedback.
Check your Gerrit settings and make sure you're getting email notifications. If your code fails automated tests, or you got some review already, respond to it in a comment or resubmission. Or hit the Abandon button to remove your commit from the review queue while you revise it.
(To see why automated tests fail, click on the link in the "failed" comment in Gerrit, hover over the failed test's red dot, wait for the popup to show, and then click "console output.")
- Don't mix rebases with changes.
When rebasing, only rebase. That makes it easier to use the "Old Version History" dropdown, which greatly quickens reviews. If non-rebase changes are made inside a rebase changeset, you have to read through a lot more code to find it and it's non-obvious.
- Add reviewers.
I try to help with this. If I notice an unreviewed changeset lingering, then I add a review request or two. (These are requests -- there's no way to assign a review to someone in Gerrit.) But it's faster if you do it right after committing. Some tricks:
- Click the name of the repository ("Gerrit project"), e.g.
operations/debs/squid , and remove "status:open" from the search box to find other changesets in that repository. The people who write and review those changesets would be good candidates to add as reviewers.
- Search through other commit summaries and changesets. Example:
Matmarex and Foxtrott are interested in reviewing frontend changes, so I search for "message:css" to find changesets that mention CSS in their commit summaries to add them to. You can use this and regexes to find changes that touch the same components you're touching, to find likely reviewers. Learn more at https://gerrit.wikimedia.org/r/Documentation/user-search.html .
- Review more.
Many eyes make bugs shallow. Read the code review guide and help out with comments, "+1", and "-1". Those are nonbinding, won't cause merges or rejections, and have no formal effect on the code review. But you'll learn, gain reputation, and get people to return the favor by reviewing you in the future. "How to review code in Gerrit" has the step-by-step explanation. Example Gerrit search for MediaWiki commits that have not had +1, +2, -1, or -2 reviews yet: https://gerrit.wikimedia.org/r/#/q/-CodeReview%252B1+-CodeReview%252B2+-Code...
Something which needs so much text, is broken is some respect. "Mies van der Rohe: Less is more."