2. Create a changelist. We use Subversion, but use some tools on top of it for the review and committing process. Make a changelist with the gcl change command. The changelist name is only to help you refer to it on your local computer, so call it whatever you want:

This will open your text editor. Write the change description at the top of the file. The description should describe what your patch changes and why. This is important for people who are looking at commit logs in the future to track down an issue: they should be able to see why you changed it without going anywhere else. You should also add a BUG=bug_number line at the end of the description so they can find the associated bug. Example:
Cut and paste the filenames above or below the divider to add files to or remove files from the changelist. You can use the gcl opened command to see your changed files and changelists:

3. Upload your change. Use the gcl upload command:

The review process

Chromium reviewers try to review code that conforms to these 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 and update the patch set in the issue by re-running gcl upload as above. Once you're ready for another review, use Publish+Mail Comments again to send another notification (you can say something like "new snapshot uploaded").  When the reviewer is happy with your patch, they will say something like "OK" or "LGTM" ("Looks Good To Me").

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.

Check in your changes

• If you have access to commit to the repository, once you've got a positive review ("OK" or "LGTM") you can go ahead and check in your code. Do this by running
  
      gcl commit changelist_name
  
  Resist the temptation to just run svn commit, since (a) this will by default submit everything modified and not just your changelist, and (b) gcl commit will automatically create a log message based on your issue description. The descriptions are very important for tracking which bugs were fixed and why a certain change was made.
  
  
• If the most recent set of changes to the repository breaks Chromium, we say the tree is red, or closed.  You cannot check in your changes until it is green again.  Check  the BuildBot waterfall to see that the first three columns are green before checking in your changes.  Otherwise, you will not know if your changes break Chromium or not.
  
  
• If you can't commit, ask the reviewer to commit your fix for you. They will patch their working copy with your changelist and commit it for you.
  
  
• Reviewers: If you are committing a fix for a contributor who cannot do it themselves, you should credit the contributor in the log comment, e.g. "Patch by Joe Smith <foo@bar.com>". Make sure they're added to the AUTHORS file too.

Be responsible

• Once you've checked something in, you're on the hook for making sure the BuildBot waterfall stays healthy, so stick around and watch them until everything cycles green. If you break something, you have to fix it. This includes tests and performance regressions. If you don't fix these things in a timely fashion, your change may be removed.
• If you don't immediately know what's wrong, be pro-active and back out your change. Other engineers shouldn't have to wait for you to debug. When the tree is red, everyone is blocked. People can't check in, and people can't sync.
• If you worked with a reviewer to commit your change, be on hand to address problems should they arise when the reviewer checks in your code.
• Be available online (IRC and IM work) so that the sheriff can contact you if something goes wrong. The sheriff is responsible for keeping the tree open and changes moving through the system, which means correcting issues when they arise.