wiki:CommitterTips

Version 1 (modified by eric@webkit.org, 14 years ago) (diff)

--

Tips and Tools for Committers and Reviewers

You're reading this because you're a newly minted WebKit Committer or Reviewer. See the http://webkit.org/coding/commit-review-policy.html WebKit Committer and Reviewer Policy for more information.

Becoming a committer

  1. After you've fulfilled the requirements outlined in the http://webkit.org/coding/commit-review-policy.html WebKit Committer and Reviewer Policy, a reviewer will nominate you on webkit-reviewers@lists.webkit.org.
  2. 2 other reviewers must second your nomination.
  3. After 5 business days your nomination carries and someone from Apple (most often Adele Peterson) will contact you with paperwork to sign and send back.
  4. After your paperwork has been received by Apple, someone will contact you (most often Mark Rowe or William Siegrest) will contact you with information about your login credentials.

Becoming a reviewer

  1. After you've fulfilled the requirements outlined in the http://webkit.org/coding/commit-review-policy.html WebKit Committer and Reviewer Policy, a reviewer will nominate you on webkit-reviewers@lists.webkit.org.
  2. 2 other reviewers must second your nomination
  3. After 5 business days your nomination carries.
  4. A reviewer will contact you to make sure you accept the nomination.
  5. Afterwards, a reviewer will post on the webkit blog to announce your acceptance and congratulate you!

Lists you should be on

Tools you should know to use

  • bugzilla-tool see --help for more information. Most useful are the and land-diff, land-patches subcommands.
  • svn-apply is how we apply patches from bugzilla. (bugzilla-tool apply-patches and bugzilla-tool land-patches uses svn-apply under the covers.)
  • svn-apply has various helpful flags including --reviewer.

Walking you through your first commit

(Next time someone does this, we should document this.)

Guidelines for committers

  • Build fixes do not need review.
  • Committers are the gate-keepers of the project. That's why you signed the agreement. Only commit patches which have been reviewed.

Guidelines for reviewers

  • There are no "protected areas" of the code. No areas were only one reviewer has say. Reviewers should review anything they feel comfortable reviewing. If you are looking for experts in a certain area, trac and svn's annotate feature can help show you who has changed the relevant lines of code recently.
  • Reviews should come to consensus before landing. If another reviewer objects, it's better to mark the patch r- and discuss than to land a patch without consensus.