wiki:CommitterTips

Version 6 (modified by adele@apple.com, 10 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 Adele Peterson or William Siegrest) 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 and a reviewer will contact you to make sure you accept the nomination.
  4. Afterwards, a reviewer will post on the webkit blog to announce your acceptance and congratulate you!

Lists you should be on once you have commit access

Tools you should know to use

  • webkit-patch see --help for more information. Most useful are the and land and upload subcommands.
  • svn-apply is how we apply patches from bugzilla. (webkit-patch apply and webkit-patch apply-from-bug use 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.