| | 1 | = Tips and Tools for Committers and Reviewers = |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | == Becoming a committer == |
| | 6 | 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`. |
| | 7 | 1. 2 other reviewers must second your nomination. |
| | 8 | 1. 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. |
| | 9 | 1. 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. |
| | 10 | |
| | 11 | == Becoming a reviewer == |
| | 12 | 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`. |
| | 13 | 1. 2 other reviewers must second your nomination |
| | 14 | 1. After 5 business days your nomination carries. |
| | 15 | 1. A reviewer will contact you to make sure you accept the nomination. |
| | 16 | 1. Afterwards, a reviewer will post on the [http://webkit.org/blog/ webkit blog] to announce your acceptance and congratulate you! |
| | 17 | |
| | 18 | == Lists you should be on == |
| | 19 | * [http://lists.webkit.org/mailman/listinfo.cgi/webkit-committers webkit-committers@lists.webkit.org] |
| | 20 | * [http://lists.webkit.org/mailman/listinfo.cgi/webkit-committers webkit-reviewers@lists.webkit.org] (reviewers only) |
| | 21 | * [http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/committers.py WebKitTools/Scripts/modules/committers.py] (the list our scripts use to know you're a committer/reviewer) |
| | 22 | * Your [https://bugs.webkit.org/userprefs.cgi?tab=permissions bugzilla account] needs `editbugs` set if it does not have it already (so you can change the components of bugs, etc.) Ask on webkit-committers if your account is missing this flag. |
| | 23 | |
| | 24 | == Tools you should know to use == |
| | 25 | * [http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/bugzilla-tool bugzilla-tool] see `--help` for more information. Most useful are the and `land-diff`, `land-patches` subcommands. |
| | 26 | * `svn-apply` is how we apply patches from bugzilla. (`bugzilla-tool apply-patches` and `bugzilla-tool land-patches` uses svn-apply under the covers.) |
| | 27 | * `svn-apply` has various helpful flags including `--reviewer`. |
| | 28 | |
| | 29 | |
| | 30 | == Walking you through your first commit == |
| | 31 | (Next time someone does this, we should document this.) |
| | 32 | |
| | 33 | == Guidelines for committers == |
| | 34 | * Build fixes do not need review. |
| | 35 | * Committers are the gate-keepers of the project. That's why you signed the agreement. Only commit patches which have been reviewed. |
| | 36 | |
| | 37 | == Guidelines for reviewers == |
| | 38 | * 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. |
| | 39 | * 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. |
