See Get the Code for details on how to checkout the code, and Design Documents for information regarding our design process. Also check out Contributing to Chromium for general information how to contribute to any Chromium project (including its developer tools).
Check out the documentation about creating a change in Chromium and uploading a change for review in Chromium, what's said in there basically applies to the devtools-frontend
repository as well.
At least two committers need to have been involved in the CL (change list) either as reviewer or author. See the committers policy for more information.
In a nutshell, optimize for meaningful CL (change list) descriptions:
Descriptions for CLs should comply with Google's Best Practices for good CL descriptions and follow the Chromium-specific CL description tips. We strive to have CL descriptions that properly capture both the what and the why of the change and ideally make sense on their own:
Descriptions should be formatted as follows:
[area] 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 Fixed: 654321 Doc: design doc and/or PRD (go/, bit.ly/ or goo.gle/ short link) Demo: URL of some demo (ideally on devtools-dbg-stories.netlify.app) Before: URL of screenshot before change After: URL or screenshot after change
The individual items here are as follows:
The first line should be a short summary of what exactly changed with this CL. The [area]
is optional, but strongly encouraged to give an immediate idea of what's affected (the most) by the change. For example if you fix a bug in the Sources panel, prefixing the first line with [sources]
makes this clear.
The description should briefly describe the motivation for the change when appropriate (the why) and then go into a detailed description of what was changed specifically and how. You may find yourself repeating some of the information that is already found in the product requirements or the design document, but that's fine, because the time saving later when trying to understand the impact of a CL can be significant, and also the PRD or DD can evolve and might no longer appropriately capture the why and the what for this particular CL.
Every CL that lands has to have a Bug: <ID>
or Fixed: <ID>
line, referencing the relevant crbug(s).
b:<ID>
or b/<ID>
since that creates an internal link.Bug: none
, for example to fix typos or update documentation (outside of the scope of a project).Every CL that is part of a bigger project should reference a design document (DD) via the Doc:
line. It might also reference a product requirements document (PRD) directly, but that should rarely be the case (instead the DD should include appropriate references to the PRD).
For public docs, consider adding a bit.ly/
or goo.gle/
short link.
Googlers: Don't forget to create the mandatory go/chrome-devtools:<project-name>-design
short link. For internal docs, use only the go/chrome-devtools:<project-name>-design
short link directly, for public docs, you can optionally list the go/
link in addition to the bit.ly
or goo.gle
short link.
The Demo:
, Before:
, and After:
lines are primarily there to support the Developer Advocates and Tech Writers (see go/help-document-devtools).
Demo:
should ideally be pushed to ChromeDevTools/devtools-dbg-stories and will thus be automatically available on devtools-dbg-stories.netlify.app.Before:
and After:
please link directly to hosted images (preferably PNGs); these links can be either public services (like imgur.com) or hosted internally (on screen/).See the section about Creating demos for crbugs and check out the README for more information about non-trivial test cases and the like.
Merge request/approval is handled by Chromium Release Managers. DevTools follows Chromium's merge criteria. In exceptional cases please get in touch with hablich@chromium.org.
Step-by-step guide on how to merge:
Merge-Request
filed of the relevant crbug. A bot will come by and either ask for more info (example) or approve the request.chromium/xxxx
(e.g. chromium/3979
) branch on the DevTools frontend repo. Use https://chromiumdash.appspot.com/branches or Omahaproxy to find out what branch a major Chromium version has (column true_branch
).chromium/3968
.If the approach above causes conflicts that need resolving, you can use an alternative git workflow which allows you to resolve conflicts locally before uploading. This is very similar to the chromium git merge steps but with different branch names. These steps will create the cherry-pick CL via git.
It is suggested to use the Gerrit UI approach when possible, it is more straightforward and automated. Only use this approach if your cherry-pick causes conflicts.
For the commands below, replace xxxx
with the Chromium branch number that you are merging into.
To set up your local environment run:
gclient sync --with_branch_heads git fetch git checkout -b BRANCH_NAME origin/chromium/xxxx git cl upstream origin/chromium/xxxx
You can then cherry-pick your commit from the main branch:
git cherry-pick -x YOUR_COMMIT
You can then resolve any conflicts, run tests, build DevTools, etc, locally to verify everything is working. Then run git cl upload
to upload the CL and get a review as normal.
Make sure you remove the Change-ID: line from the description to avoid issues when uploading the CL.