| | 1 | = Submitting Patches = |
| | 2 | |
| | 3 | == Get set up == |
| | 4 | |
| | 5 | * Make a Bugzilla account at http://bugs.webkit.org/. |
| | 6 | * Add {{{<your Subversion working copy>/WebKit/WebKitTools/Scripts}}} to your shell path. |
| | 7 | |
| | 8 | == Submit a patch == |
| | 9 | |
| | 10 | === Verify the problem === |
| | 11 | |
| | 12 | * Update your build by running {{{update-webkit}}} followed by {{{build-webkit}}}. |
| | 13 | * Make sure the problem you're fixing still exists by running {{{run-safari}}}. |
| | 14 | |
| | 15 | === Create a testcase === |
| | 16 | |
| | 17 | * See the documentation on [http://webkit.org/quality/testing.html running tests], [http://webkit.org/quality/testwriting.html writing new tests], and [wiki:"Writing Layout Tests for DumpRenderTree"] |
| | 18 | * Run {{{run-webkit-tests}}} to see if your bug fix fixes an existing broken testcase. (If it breaks a test that passed before, be ''sure'' your fix is correct before submitting it.) |
| | 19 | * Otherwise, create a new testcase. |
| | 20 | * Many tests are HTML files containing !JavaScript that exercises a single feature or sub-feature and produces a reliable, easily recognizable result. For example, see {{{fast/events/event-creation.html}}} or {{{fast/dom/HTMLSelectElement/listbox-select-reset.html}}}. |
| | 21 | * It's also possible to create a testcase that produces a PNG file and checksum to be compared with an expected result, if you're testing things like colors. For example, see {{{fast/dom/css-rule-functions.html}}}. For that, be sure ''not'' to use {{{layoutTestController.dumpAsText()}}}. |
| | 22 | * Create the expected result file(s). |
| | 23 | * If your fix fixes an existing test (or breaks one, but you're certain it's correct), delete the existing expected result(s) for that test so a new expected result can be generated. |
| | 24 | * Run your new test(s). To run only a subset of the full test suite, run {{{run-webkit-tests}}} with the paths of the test directories or files relative to your {{{LayoutTests}}} directory. For example, {{{run-webkit-tests fast/dom/HTMLSelectElement/}}} will run all the tests in that directory. If you want to generate PNGs and checksum files too, add the {{{-p}}} option to {{{run-webkit-tests}}}. |
| | 25 | * After the tests are done, the test system will launch your newly built Safari and offer to show the actual results of any tests that have no expected results, as well as diffs of the expected and actual results when applicable. It will automatically create the expected result files for any new tests, so look at their results and make sure they're correct. |
| | 26 | * If you need to make further changes, you can remove an expected result file and re-run its test to generate a new one. Or, you can run the test with the old expected results in place, and copy the new actual result from /tmp to the correct expected result file. (Don't just copy and paste from the window, because it's hard to make sure that all the whitespace is exactly right.) |
| | 27 | * When you're happy with the expected result, run the test again to be sure it now passes. |
| | 28 | |
| | 29 | === Prepare the patch === |
| | 30 | |
| | 31 | * Find, or file, an appropriate bug for your patch in [http://bugs.webkit.org/ Bugzilla], following the [http://webkit.org/quality/bugwriting.html bug-reporting guidelines]. |
| | 32 | * See [http://webkit.org/coding/contributing.html the WebKit guide to contributing code]. |
| | 33 | * {{{svn add}}} any new files you're adding. |
| | 34 | * Run {{{prepare-ChangeLog}}} from a directory that contains all of your changes (to be safe at the expense of speed, you can use the top of your working copy). |
| | 35 | * Examine the output from that script and manually edit any !ChangeLog files it edited. Add bug reference(s) and brief descriptions for each change, following the examples in the file. Be sure to use spaces rather than tabs, just like in source code. |
| | 36 | * Make the actual patch by running {{{svn-create-patch > patch.txt}}}. Your testcase changes and the lines you added to ChangeLog(s) will show up as part of the patch, which is what you want. (If they don't, probably you either need to {{{svn add}}} the files or you ran {{{svn-create-patch}}} from too deep a directory.) |
| | 37 | |
| | 38 | === Submit it === |
| | 39 | |
| | 40 | * Attach your patch to the Bugzilla bug and set {{{review?}}} on it, leaving the requestee field empty. Wait for review. |
