This page assumes a working Chromium checkout and build. Note that a full Chromium checkout includes external repositories with their own workflows for contributing, such as v8 and Skia. Similarly, ChromiumOS, which includes Chromium as a subrepository, has its own development workflow.
When writing a new feature or fixing an existing bug, get a second opinion before going too far. If it‘s a new feature idea, propose it to the appropriate discussion group. If it’s in the existing code base, talk to some of the folks in the “OWNERS” file (see code review policies for more) for the code being changed.
All contributors must complete the contributor license agreement. For individual contributors, please complete the Individual Contributor License Agreement online. Corporate contributors must fill out the Corporate Contributor License Agreement and send it to us as described on that page.
Add your (or your organization's) name and contact info to the AUTHORS file for Chromium or Chromium OS. Please include this as part of your first patch and not as a separate standalone patch.
Before LGTMing a change from a non-chromium.org address, ensure that the contribution can be accepted:
git config --global user.name "My Name" git config --global user.email "myemail@chromium.org" git config --global core.autocrlf false git config --global core.filemode false git config --local gerrit.host true # Uncomment this if you want your pull commands to always rebase. # git config --global branch.autosetuprebase always # Uncomment if you want new branches to track the current branch. # git config --global branch.autosetupmerge always
First, create a new branch for your change in git. Here, we create a branch called mychange (use whatever name you want here), with origin/master as the upstream branch.
git checkout -b mychange -t origin/master
Write and test your change.
Commit your change locally in git:
git commit -a
If you are not familiar with git, GitHub's resources to learn git is useful for the basics. However, keep in mind that the Chromium workflow is not the same as the GitHub pull request workflow.
Chromium uses a Gerrit instance hosted at https://chromium-review.googlesource.com for code reviews. In order to upload your local change to Gerrit, use git-cl from depot_tools to create a new Gerrit change, based on the diff between the current branch and its upstream branch:
git cl upload
This will open a text editor to create a description for the new change. This description will be used as the commit message when the change is landed in the Chromium tree. Descriptions should be formatted as follows:
Summary of change (one line) Longer description of change addressing as appropriate: why the change is made, context if it is part of many changes, description of previous behavior and newly introduced differences, etc. Long lines should be wrapped to 72 columns for easier log message viewing in terminals. Bug: 123456
A short subject and a blank line after the subject are crucial: git uses this as a heuristic for tools like git log --oneline. Use the bug number from the issue tracker (see more on CL footer syntax). Also see How to Write a Git Commit Message, which has more in-depth tips for writing a good commit description.
Links to previous CLs should be formatted as https://crrev.com/c/NUMBER, which forwards to Gitiles, rather than linking to the review at https://chromium-review.googlesource.com.
If there are instructions for testers to verify the change is correct, include them with the Test: tag:
Test: Load example.com/page.html and click the foo-button; see crbug.com/123456 for more details.
After saving the change description, git-cl runs some presubmit scripts to check for common errors. If everything passes, git-cl will print something like this:
remote: SUCCESS remote: remote: New Changes: remote: https://chromium-review.googlesource.com/c/chromium/src/+/1485699 Use base::TimeDelta::FromTimeSpec helper in more places. [WIP]
Additional flags can be used to specify reviewers, bugs fixed by the change, et cetera:
git cl upload -r foo@example.com,bar@example.com -b 123456
See git cl help upload for a full list of flags.
Code reviews are covered in more detail on the code review policies page.
Ideally, the reviewer is someone who is familiar with the area of code in question. If you're not sure who that should be, check with anyone in the nearest ancestor OWNERS file.
git cl owners automatically suggests reviewers based on the OWNERS files.Open the change on the web. If you can't find the link, running git cl issue will display the review URL for the current branch. Alternatively, visit https://chromium-review.googlesource.com and look in the “Outgoing Reviews” section.
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 automated tests.
Click Add Reviewers in the left column (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.
In the same dialog, you can include an optional message to your reviewers. This space can be used for specific questions or instructions. Once you're done, make sure to click Send, which notifies the requested reviewers that they should review your change.
IMPORTANT: UNTIL YOU SEND THE REVIEW REQUEST, NO ONE WILL LOOK AT THE REVIEW
All changes must be reviewed (see code review policies).
You should get a response within one business day; re-ping your reviewers if you do not.
To upload new patch sets that address comments from the reviewers, simply commit more changes to your local branch and run git cl upload again.
When the reviewer is happy with the change, they will set the “Code-Review +1” label. Owners of all affected files must approve before a change can be committed. See: code review policies: owners.
Before being submitted, a change must pass the commit queue (CQ). The commit queue is an automated system which sends a patch to multiple try bots running different platforms: each try bot compiles Chromium with the patch and ensures the tests still pass on that platform.
To trigger this process, click CQ Dry Run in the upper right corner of the code review tool. Note that this is equivalent to setting the “Commit-Queue +1” label. Anyone can set this label; however, the CQ will not process the patch unless the person setting the label has try job access.
If you don't have try job access and:
The status of the latest try job for a given patchset is visible just below the list of changed files. Each bot has its own bubble, using one of the following colors to indicate its status:
Changes should generally be committed via the commit queue. This is done by clicking Submit to CQ in the upper right corner, or setting the “Commit-Queue +2” label on the change. The commit queue will then send the patch to the try bots. If all try bots return green, the change will automatically be committed. Yay!
Sometimes a test might be flaky. If you have an isolated failure that appears unrelated to your change, try sending the change to the commit queue again.
Alternatively, a developer with commit access can directly commit a change, bypassing the commit queue. This should only be used in emergencies because it will bypass all the safety nets.
During the lifetime of a review, you may want to rebase your change onto a newer source revision to minimize merge conflicts. The reviewer-friendly way to do this is to first address any unresolved comments and upload those changes as a patchset. Then, rebase to the newer revision and upload that as its own patchset (with no other changes). This makes it easy for reviewers to see the changes made in response to their comments, and then quickly verify the diffs from the rebase.
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.