Using GitHub to Contribute to WebKit (Proposal)

Sometimes when folks are developing an experimental feature, they feel stressed by WebKit's current code review system because breaking their feature down into many small patches that land over a period of weeks makes it harder for them to iterate on the feature. This document describes an alternative process for contributing to WebKit that uses a more git-like approach based on GitHub's tools. This process is somewhat experimental, but it might work well for folks who are familiar with git-style development and are working on largely self-contained features.

Because this process is experimental, you'll probably want to line up a reviewer for you changes ahead of time to make sure they're interested in using this process.

Setup

1. Create a GitHub account (if you don't already have one)
2. Fork ​https://github.com/WebKit/webkit
3. $ git clone git@github.com:yourname/webkit.git

Writing code

1. $ git checkout master -b awesomefeature
2. Write some awesome code.
3. Commit locally and push to origin (your GitHub account) as you normally would with git

Tracking upstream

1. One-time setup: $ git remote add upstream git://github.com/WebKit/webkit.git
2. $ git fetch upstream
3. $ git merge upstream/master
4. $ git push origin master

If you never modify your local master branch, merging upstream/master will always be a fast-forward merge (i.e., no merge conflicts). You can then merge these new commits into your in-flight feature branches as you normally would with git.

Getting your code reviewed

1. Find a reviewer who is interested in reviewing your awesome feature.
2. Push your lastest commits to your feature branch (e.g., $ git push origin awesomefeature)
3. Create a pull request by going to ​https://github.com/yourname/webkit/pull/new/awesomefeature
4. Click the "Change Commits" button to select that reviewer's WebKit repo as the "base branch". TODO: Investigate whether we can make reviewers members of the "WebKit" organization so we can just use WebKit/webkit@master as the base branch.
5. Write a helpful description of your pull request and click "Send pull request".
6. Iterate with the reviewer as usual using GitHub's review tools.

Landing a patch

TODO: If we're going to use this process, we'll probably want to teach webkit-patch how to automatically fill in the ChangeLog description and "Reviewed by" lines from the pull request.

1. If you're landing a patch for someone else, first download and apply the patch: $ curl https://github.com/yourname/webkit/pull/7.patch | git am
2. $ ./Tools/Scripts/webkit-patch upload --no-review (Note: This will upload the current branch as one patch to a newly created bugs on ​https://bugs.webkit.org/.)
3. Fill in the ChangeLog description from the pull request, and fill out the "Reviewed by" line based on who reviewed your patch. (Please include a link to the pull request in case folks want to read the discussion.)
4. Go to the ​https://bugs.webkit.org/ bug for your patch and set the commit-queue+ flag. (If you're not a committer, you'll need to ask a committer to set that flag for you.)