If you want to contribute code to Chromium, there are a few things you can do to make the process flow smoothly. For Chromium OS, please go here.
Quick start guide: Life of a Chromium Developer
Note: These instructions apply only if your changes are in Chromium code. If your changes are in a directory that we pull from another repository (e.g. Blink, v8, skia, gtest, gmock), you need to use that project's way of getting code submitted. For example, here is a cheatsheet for contributing to Blink, and here's Chrome DevTools. Once your change has landed upstream, you need to update Chromium's DEPS file to pull in the new revision (we update Blink very often, so you don't have to take care of this if you're contributing to Blink).
Creating a change in git is really just creating a branch.
Rietveld is the open source code review tool we use. We use an AppEngine instance at http://codereview.chromium.org.
If you specified Remail@example.com in the CL description, they will be emailed automatically so use --send-mail so you don't need to visit the web UI.
Go to the supplied URL or just go to the respective code review page (Chromium | Chromium OS) and click Issues created by me. Select the change you want to submit for review and click Edit Issue. Enter at least one reviewer's email address and click Update Issue. Now click on Publish+Mail Comments, add any optional notes, and send your change off for review. All Chromium code reviews are automatically cc'd to their respective review groups, so that everyone has an opportunity to see and comment on the changes being made.
Note: If you don't see editing commands on the review page, click Log In in the upper right.
Hint: You can add
Ideally, the reviewer is someone who is familiar with the area of code you are touching. If you have doubts, look at the
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 and update the patch set in the issue by uploading again.
If you need to update the code on an already uploaded CL, simply
Once you're ready for another review, use Publish+Mail Comments again to send another notification (you can say something like "new snapshot uploaded" or PTAL "Please Take A/Another Look").
Note: As you work through the review process, both you and your reviewers should converse using the code review interface, and send notes using Publish+Mail Comments. Avoid the temptation to respond directly to review mails (or, for reviewers, to send review comments) directly from your email client; doing that won't add your comments to the online record for the issue under review, and can make it hard for others to understand later what the history of a patch was.
When the reviewer is happy with your patch, they will say "LGTM" ("Looks Good To Me"). The reviewer types this exact text (case-insensitive, so "lgtm" also works) 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, you can instead list the OWNERS in the
The preferred way of committing changes is via the commit queue. This is done by checking the "commit" check box in Rietveld, or from the command line via
Alternatively, it is possible to directly commit your change, bypassing the commit queue. This is discouraged, due to not running the tests, and requires more supervision on the part of the committer, but is acceptable or necessary in certain circumstances. Only committers can commit changes. If you are not a committer, you should try to commit via the commit queue first. If that doesn't work for some reason, ask your reviewer to commit it for you, and add "Contributed by firstname.lastname@example.org" in your change description for clarity.
Most contributions consist of individual patch sets (change lists), which are reviewed and processed through Rietveld. For more complex situations, one can use a remote git branch on the writable git repository; this allows one to use git push and collaborate or just post code dumps. See [blink-dev] A writable git repo for collaboration and code dumps for details. (Blink) branches should be pushed to: https://chromium.googlesource.com/experimental/chromium/blink.