Changeset 48488 in webkit
- Timestamp:
- Sep 17, 2009 1:07:11 PM (15 years ago)
- Location:
- trunk/WebKitSite
- Files:
-
- 2 edited
-
ChangeLog (modified) (1 diff)
-
coding/contributing.html (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/WebKitSite/ChangeLog
r48226 r48488 1 2009-09-17 Eric Seidel <eric@webkit.org> 2 3 Reviewed by Darin Adler. 4 5 Update contributing.html to mention recently added tools. 6 https://bugs.webkit.org/show_bug.cgi?id=29318 7 8 Update our contributing instructions to mention 9 the new tools (check-webkit-style and commit-queue) 10 recently added to make contributions easier. 11 12 * coding/contributing.html: 13 - Mention check-webkit-style as an optional helper tool. 14 - Mention checking the 'patch' checkbox. 15 - Mention the commit-queue as an optional helper tool. 16 - Remove "or in email" since patch reviews are all done via bugzilla. 17 - Encourage contributers to be responsible for getting their patch landed. Provide a list of committers. 18 - Mention commit-queue as an optional help in getting your patch landed. 19 - Give an overview of the commit-queue process and link to the Commit Queue docs. 20 1 21 2009-09-09 Tor Arne Vestbø <tor.arne.vestbo@nokia.com> 2 22 -
trunk/WebKitSite/coding/contributing.html
r47428 r48488 7 7 Once you have the code <a href="/building/checkout.html">checked out</a>, <a href="/building/build.html">built</a>, and made your changes, you'll need to do a few things in order to get it landed in the tree:</p> 8 8 <ol> 9 <li>Make sure your changes meet the <a href="/coding/coding-style.html">code style guidelines</a>. </li>9 <li>Make sure your changes meet the <a href="/coding/coding-style.html">code style guidelines</a>. <tt>check-webkit-style</tt> may be of help.</li> 10 10 <li>Run the layout tests using the <tt>run-webkit-tests</tt> script and make sure they all pass. 11 11 See the <a href="/quality/testwriting.html">testing page</a> for more information, as well as what you need to do if you've modified JavaScriptCore.</li> … … 13 13 <li>Prepare a change log entry. You may have to add entries to multiple ChangeLogs. The <tt>prepare-ChangeLog</tt> script will create stub entries for you. See the <a href="#changelogs">paragraph about ChangeLogs</a> below.</li> 14 14 <li>Create the patch using the <tt>svn-create-patch</tt> script.</li> 15 <li>Upload the patch for review. In Bugzilla, be sure to set the <tt>review:?</tt> flag.</li>15 <li>Upload the patch for review. In Bugzilla, be sure to mark your file as a patch and set the <tt>review:?</tt> flag.</li> 16 16 <li>Make any changes recommended by the reviewer.</li> 17 <li>Once reviewed, get your patch landed in the tree and watch for any regressions it may have caused (hopefully none)!</li> 17 <li>Once reviewed, ask someone to land your patch or mark it for <a href="#commitqueue">automated commit</a>. 18 <li>Please watch for any regressions it may have caused (hopefully none)!</li> 18 19 </ol> 19 20 … … 57 58 <p>Once you have a patch file, it must be reviewed by one of the approved WebKit reviewers. To request a review, attach the patch 58 59 to the bug report, and mark the patch with the flag <tt>review:?</tt>. The reviewer will typically either approve the patch 59 (by responding with an <tt>r=me</tt> in the bug report or in e-mailand marking the patch <tt>review:+</tt>) or request revisions60 (by responding with an <tt>r=me</tt> in the bug report and marking the patch <tt>review:+</tt>) or request revisions 60 61 to the patch (and mark the patch <tt>review:-</tt>). In rare cases a patch may be permanently rejected, meaning that the reviewer 61 62 believes the feature should never be committed to the tree. The review process can consist of multiple iterations between you and 62 63 the reviewer as revisions are made to your patch.</p> 63 64 64 <h3>Landing in the tree</h3> 65 <p>Once a patch is approved, someone with commit access will land your patch. Your responsibility for the patch does not end with 66 the patch landing in the tree. There may be regressions from your change or additional feedback from reviewers after the patch has landed. You can watch the tree at <a href="http://build.webkit.org">build.webkit.org</a> to make sure your patch builds and passes tests on all platforms. 65 <h3><a name="landing">Landing in the tree</a></h3> 66 <p>Once a patch is approved, you should ask <a href="https://lists.webkit.org/mailman/roster.cgi/webkit-committers">someone with commit access</a> to land your patch. Alternatively you can request that your patch be committed by our <a href="#commitqueue">commit bot</a>. In either case, your responsibility for the patch does not end with the patch landing in the tree. There may be regressions from your change or additional feedback from reviewers after the patch has landed. You can watch the tree at <a href="http://build.webkit.org">build.webkit.org</a> to make sure your patch builds and passes tests on all platforms. 67 67 It is your responsibility to be available should regressions arise and to respond to additional feedback that happens after a check-in.</p> 68 69 <h3><a name="commitqueue">Optional: Use of the WebKit Commit Bot</a></h3> 70 <p>WebKit provides an automated system (commit-queue) for landing patches for any who would like to use it. To use the commit-queue, set the <tt>commit-queue:?</tt> flag on your patch. A committer will set <tt>commit-queue:+</tt> and an automated process will download, build, run the layout tests, and submit your patch on your behalf. If the <a href="http://build.webkit.org/">WebKit buildbots</a> are passing, your patch should be landed within 15 minutes after <tt>commit-queue:+</tt> is set. See the <a href="https://trac.webkit.org/wiki/CommitQueue">commit-queue documentation</a> for more information.</p> 68 71 69 72 <h2>WebKit Scripts</h2>
Note: See TracChangeset
for help on using the changeset viewer.
