Changes between Version 8 and Version 9 of WebKitGTK/StartHacking

Jun 19, 2013 9:27:55 AM (8 years ago)
Andres Gomez

Added contributin patches section


  • WebKitGTK/StartHacking

    v8 v9  
    93 $ ccache -C
     93ccache -C
    127127As you code new features and fix bugs you will need to rebuild the sources or dependencies. You have to be careful if you don't want to waste time. You don't want compiled code to be swiped by mistake given the time that it takes to build it.
    129 The build result is located in the ''WebKitBuild'' directory. ''Release'' builds will be place under ''WebKitBuild/Release''' while Debug builds will be placed under ''WebKitBuil/Debug''.
     129The build result is located in the ''WebKitBuild'' directory. ''Release'' builds will be place under ''WebKitBuild/Release'' while Debug builds will be placed under ''WebKitBuil/Debug''.
    131131As you should know by now, building dependencies will typically be gotten with the help of ''jhbuild''. The default command for this, as explained in BuildingGtk is:
     215== Contributing patches ==
     217This 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 [ 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
     223Steps to upload a patch to [ 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):
     228$ Tools/Scripts/prepare-ChangeLog
     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.
     240 * Upload your patch:
     243$ Tools/Scripts/webkit-patch upload
     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
     253 * Then you could check in the bugzilla if the [ 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?`.