mail at tgries
Aug 29, 2012, 3:05 PM
Post #2 of 10
Am 29.08.2012 23:55, schrieb Sumana Harihareswara:
Re: 5 tips to get your code reviewed faster
[In reply to]
> Version with helpful links:
> 1) 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.
> 2) 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.")
> 3) 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.
> 4) 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 .
> 5) 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:
Something which needs so much text, is broken is some respect.
"Mies van der Rohe: Less is more."
Wikitech-l mailing list
Wikitech-l [at] lists