This page covers contributing code to the main Chromium repository. It assumes you already have a working checkout and build. A full checkout pulls many other repositories such as v8 and Skia which have their own repositories and processes. Chromium it itself pulled into ChromiumOS which has its own process.
Start with a branch in git. Here we create a branch called
Write and test your code.
Commit your patch locally in git (you may want to do search for git tutorials if you are unfamiliar with it).
This will create a Reitveld "issue" for you. You will be prompted for a description, and some presumbit checks will also be run to identify common errors. When it is done it will print the URL you can use to see the change on the web.
Use the following form:
You can optionally include your code reviewer at the bottom (this saves you from having to type it into the web UI):
If there are instructions for testers to verify your change is correct, append:
Ideally the reviewer is someone who is familiar with the area of code you are touching. If you have doubts, look at the
Open the change on the web (if you can't find the link, run
Reviewers expect to review code that compiles and passes tests. If you have access, now is a good time to run your change through the automates tests (see below).
Click Edit Issue in the upper-left (if you don't see this link, make sure you are logged in). In the Reviewers field, enter a comma-separated list of the reviewers you picked, and press Update Issue.
Click Publish+Mail Comments in the upper-left (never mind that you have no comments to publish). This will send email to notify the reviewers you are requesting a review. If you have any particular questions or instructions for the code review, enter them in the Message box, but it's fine to leave this field empty. Click Publish all my drafts (never mind that you have no drafts to publish).
Reviewers try to review code that conforms to the guidelines as quickly as possible. You should hear back within 24-48 hours. Remember though, if you submit a giant patch, or do a bunch of work without discussing it with the relevant people, you may have a hard time convincing anyone to review it! Speak with others early and often. Sometimes, the tree will be locked down and certain types of changes won't be allowed. This is true when we're preparing a release. During times like these, reviewers may be focused on fixing the bugs required to get the release out the door.
Remember that code reviews are an important part of the engineering process. The reviewer will almost always have suggestions or style fixes for you, and it's important not to take such suggestions personally or as a commentary on your abilities or ideas. This is a process where we work together to make sure that the highest quality code gets submitted.
You will likely get email back from the reviewer with comments. Fix these in the code or answer questions in the code review tool. Update the patch set in the issue by re-running
When the reviewer is happy with your patch, they will say "LGTM" ("Looks Good To Me"). The reviewer types this exact text (case-insensitive) in their comment, which is detected by Rietveld and marks approval. If this is accidentally typed, writing "not LGTM" withdraws approval.
Except in rare cases, you need approval from owners of all affected files before committing. In specific cases where it is allowed (see owners guidelines), you can instead list the OWNERS as "TBR" ("To Be Reviewed") for review after commit. Add the reviewers addresses to a line at the bottom of the change description
Before being submitted, a change must pass a large series of compilations and tests across many platforms. To trigger this process, press the CQ dry run (CQ = "Commit Queue") at the bottom of the patch summary in the code review tool. This link is only available to those with permission:
Changes should generally be committed via the commit queue. This is done by checking the Commit check box below the patch in the code review tool. The commit queue will then send your patch to the try bots, which will eventually appear as colored bubbles near the checkbox in the code review tool (the same thing that happens for dry runs). If all tests pass, your change will be auto committed. If it fails, click on the red (failure) bubbles for a direct link to the failures. Sometimes a test might be flaky, if you have an isolated failure that appears unrelated to your change, wait a while and click commit again.
Alternatively, it is possible to directly commit your change, bypassing the commit queue. This should only be used in emergencies because it will bypass the tests.
Code authors and reviewers should keep in mind that Chromium is a global project: contributors and reviewers are often in time zones far apart. Please read these guidelines on minimizing review lag and take them in consideration both when writing reviews and responding to review feedback.
For Developers >