The Chromium Projects
 
Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

The Chromium OS designs and code are preliminary. Expect them to evolve.
For Developers‎ > ‎How-Tos‎ > ‎

WebKit Integration/Sheriffing

The WebKit Sheriff calendar is available here.

Now that we are completely unforked, we have switched from the vendor branch model to the integration model -- we are pulling WebKit directly from upstream and rolling DEPS when the revision is good.

The interesting question, of course is what makes a revision good? In our case, we'll let the canary bot determine that

The canary server always pulls from the tip of trunk WebKit and is a great early warning system for a possible breakage happening upstream.

In essence, it's a try bot for changes upstream.

Responsibilities

As a WebKit sheriff, your responsibility is to watch the canary server and do one of the following:

  1. Roll DEPS to pick up changes for green builds;
  2. Fix build bustage for red builds.

Rolling DEPS is just a matter of committing a change to webkit_revision variable in src/DEPS file to that of the most recent green canary build:

vars = {
  "webkit_trunk":
    "http://svn.webkit.org/repository/webkit/trunk",
  "webkit_revision": "12345",
}

Naturally, you don't have to do this for every build -- a couple of times a day should be sufficient. In some cases, your teammates may request extra rolls to grab their changes.

It is rare but possible that a green canary build wreaks havoc in the Chromium build due to unit or UI test failures. You should anticipate that and be ready to roll revision back to its previous value if something like that happens.

In case of the canary bot bustage, it is your responsibility to:

  1. Diagnose the problem;
  2. Fix it.

The bustage doesn't always result in a compile failure. Sometimes it manifests through layout test regressions. To fix, WebKit bustages require changes that generally fall somewhere in these 4 categories:

  1. Changes in Chromium tree
  2. Changes to our code in the WebKit tree
  3. Changes to common WebKit code
  4. New baselines for layout tests.

The first category is very easy to fix -- just make these changes locally and submit with your DEPS roll. Be sure to first land a DEPS roll right up to the breakage to minimize effects of other changes for your fix commit.

Changes to our code in the WebKit tree are usually a consequence of WebKit engineers not seeing our port on the WebKit build bot and should be treated as upstream build bustage. In other words, you can commit fixes to WebKit tree without a review. Just make sure to replace Reviewed by ... with Not Reviewed, build fix. in the ChangeLog. Once the canary bot picks up your commit, it should feel happier.

Changes to common WebKit code are trickier. Please hunt down the author of the breaking change on #webkit or bugs.webkit.org and work with him/her to come up with an improved version of the change -- the one that doesn't break the Chromium port. Ask the reviewer of the original change to review the fix. Hope it goes fast.

Landing Two-sided Patches

Sometimes the patch spans both WebKit and Chromium trees, which makes it somewhat tricky to land.  Here's a set of steps that should help:
  1. Make sure the canary had a green run. 
  2. Land your patch upstream.
  3. Roll up to last green revision, which should be the revision prior to your landing.
  4. Prepare a patch that rolls one revision forward, including your fix. Make sure it builds locally and/or use try bots for other platforms.
  5. Land the patch.
Layout Tests
Often, new layout tests are added to WebKit or existing tests are rebaselined. When this happens, you will need to submit new baselines for these tests. Build the test_shell locally and run layout tests with the --new-baseline option. Make sure to add newly created files to your DEPS roll. For other platforms, also add these tests to test_expectations.txt (don't forget to lint!), comment accordingly and create a "to-be-rebaselined" bug.
  1. File specific bugs for other individual tests (or groups of clearly related tests as a P1, regression with area WebKit), with as much information as you have, and assign them to the right people if possible. Any that have been dealt with like this, move up to one of the more appropriate sections of tests_fixable. If you're not sure whom to assign a bug to, leave it Untriaged, with an empty owner.
  2. When you're done, the only tests remaining in the bottom section of tests_fixable should be ones where you can't even tell if we pass them. Those should also have bugs filed, preferably with owners.
  3. For all tests that you added bugs for, add a BUG# tag (along with WIN, MAC, etc.) in front of each in the tests_fixable file where # is the chromium bug number.
  4. Run the test list linter again:  src/webkit/tools/layout_tests/run_webkit_tests.sh --lint-test-files
  5. Make a change for your tests_fixable patch, get it reviewed, and commit it.
It is very important to be careful in distinguishing between a layout test regression and a test, needing rebaseline -- we don't want to sneak regressions in under the guise of rebaselining. Err on the side of caution.
With this many possibilities for failure, please don't get discouraged when with your fix upstream, another breaking commit comes rolling in. The ebb-and-flow nature of check-ins means that some sheriffing days will be easy and some will be hard -- just like the merges. The big difference is that now we can identify breaking changes more easily and react quicker.

Rebaselining layout tests using the rebaselining tool

You could use the rebaselining tool to produce new baselines for all platforms. The tool pull baselines from archive results on Chromium buildbot (by default) or webkit.org canary (running the tool with option --webkit_canary). Click here to see details on how to use the tool.

Running layout tests on the trybots

Layout tests are supported on special trybots. To run them, use the following format:
gcl try foo --bot layout_win,layout_mac,layout_linux

Performance Regressions

The canary bots include two performance testers. One on Linux and one on Windows. The Canary Dashboard shows the results.


To view changes between merge revisions, go to:
http://trac.webkit.org/changeset?new=NEWREVISIONHERE@trunk&old=OLDREVISIONHERE@trunk

The sheriffing duty will continue in this form until we have a working builder up on the build.webkit.org. After that, we will regroup and come up with a new set of guidelines.
Subpages (1): Webkit Gardender List