| 215 | | |
| 216 | | |
| | 215 | == Contributing patches == |
| | 216 | |
| | 217 | This notes are taking into account that the WebKit repository is managed with Git and that `git-svn` is tracking the official SVN repository: |
| | 218 | * Create an account in [https://bugs.webkit.org/ WebKit bugzilla]. |
| | 219 | * Every patch goes in a different bug, so if it doesn't have bug yet report it :-) |
| | 220 | * '''WARNING''': You need to install Subversion in your system (having `git-svn` installed will help too. Follow [wiki:UsingGitWithWebKit#Checkout these instructions]. |
| | 221 | * There're more detailed info in http://www.webkit.org/coding/contributing.html |
| | 222 | |
| | 223 | Steps to upload a patch to [https://bugs.webkit.org/ WebKit bugzilla]. |
| | 224 | * You should be in a branch where you only have the changes of your patch compared to master/trunk. |
| | 225 | * Generate the `ChangeLog` files of your patch (this will generate the `ChangeLog` from the current diff not the committed patches): |
| | 226 | {{{ |
| | 227 | #!sh |
| | 228 | $ Tools/Scripts/prepare-ChangeLog |
| | 229 | }}} |
| | 230 | * Options: |
| | 231 | * `-b #bug-number#`: This will automatically fills the first 2 lines of the `ChangeLog` file. |
| | 232 | * `-g #commit-identifier#`: This allow you to generate the `ChangeLog` for an already locally committed patch. |
| | 233 | * `-o`: It automatically opens the editor with the new `ChangeLog` entries. |
| | 234 | * Fill the `ChangeLog` files modified in the previous patch. |
| | 235 | * The first line should be the bug/patch title (already done if you used `-b #bug-number#` option). |
| | 236 | * Next line is the link to the bug (already done if you used `-b #bug-number#` option). |
| | 237 | * Then you should leave the `Reviewed by NOBODY (OOPS!).` that will be automatically filled by commit-queue when the patch lands. If it's a gardening patch (e.g. skip a LayoutTest already passing) you can change that by something like `Unreviewed gardening.` as these patches don't need to be reviwed and request to someone else to do the `cq+`. |
| | 238 | * Next you should add a description about your changes. And add comments in each methods you have modified if there's anything important to explain. |
| | 239 | |
| | 240 | * Upload your patch: |
| | 241 | {{{ |
| | 242 | #!sh |
| | 243 | $ Tools/Scripts/webkit-patch upload |
| | 244 | }}} |
| | 245 | * Options: |
| | 246 | * `-g #commit-identifier#`: This allow you to upload an already locally committed patch. |
| | 247 | * `--request-commit`: To add `cq?` flag to your patch. While you're not committer you cannot do `cq+` so if you've added the flag `cq?` he'll `cq+` the patch when he `r+` it. |
| | 248 | * `--comment`: If you want to add a comment about the patch when it's uploaded to the bugzilla. |
| | 249 | * `--suggest-reviewers`: Suggests you reviewers to be included in `CC` ('''WARNING''': it only works if you have a `git-svn` repository properly configured (see [wiki:UsingGitWithWebKit#Checkout these instructions]) |
| | 250 | * `webkit-patch upload` will pass the style checker and you should fix any issue before uploading it. |
| | 251 | * It also shows you the diff of your patch that is going to be uploaded in order to check that everything is right. |
| | 252 | * Finally it requests you your credentials for https://bugs.webkit.org. |
| | 253 | * Then you could check in the bugzilla if the [https://webkit-queues.appspot.com/ Early Warning System (EWS)] detect any issue in your patch. If it doesn't apply in trunk or any port is broken because of your patch you should review your patch and upload it again. |
| | 254 | * If EWSs are green you could add some people to `CC` in order to review your patch (maybe you already done it with `--suggest-reviewers` option), be sure that the patch is marked for review `r?`. |
