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.
Related resources
Communicate
Legal stuff
Create a local branchStart with a branch in git. Here we create a branch called git checkout -b mychange origin/master 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). git commit -a Uploading a change for reviewInitial git setupAuthenticate with depot tools - make sure to authenticate with your @chromium.org account: depot-tools-auth login https://codereview.chromium.org Tell git about your name, email and some other settings. git config --global user.name "My Name" The upload command
We use the Rietveld code review tool running at codereview.chromium.org. To upload your change to Reitveld, use the 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. Code quality guidelinesWe want this code to be the best codebase you've ever worked on, and the maintainability of the code is critical:
Writing change list descriptionsUse the following form: Summary of change. Use the bug number from the issue tracker (see more on bug formatting). You can optionally include your code reviewer at the bottom (this saves you from having to type it into the web UI): R=foo@chromium.org If there are instructions for testers to verify your change is correct, append: TEST=Load example.com/page.html and click the foo-button; see Code reviewFinding a reviewerIdeally the reviewer is someone who is familiar with the area of code you are touching. If you have doubts, look at the
Requesting reviewOpen 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). The review processReviewers 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 ApprovalWhen 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 Running automated testsBefore 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:
CommittingChanges 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. TipsDuring the lifetime of a review you may want to rebase your change onto a newer source revision to minimize eventual merge pain. The reviewer-friendly way to do this is to upload the rebase as its own patchset (with no changes other than the rebase) when there are no outstanding comments. Then upload another patch with your changes. This way the reviewer can see what changes you made independent of 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. |
For Developers >