Chromium Schedule Update

Skip to first unread message

Jason Kersey

Mar 18, 2020, 8:23:18 PM3/18/20
to chromium-dev

Howdy folks,

As you may have seen, we’ve currently paused the Chromium release schedule as we work to transition much of our testing and development to happen remotely. Our top objective is to keep trunk/master in a stable, reliable state.

This means in practice we will not be promoting new milestones to stable during this period and that the scheduled release of M81 will stay on hold pending our decision to resume releases.

For our upcoming releases, we’re currently evaluating what we will do for M82 which branched last week. We plan to release another Dev channel release of M82 this week to gather more stability data. For M83, we’ll continue shipping Canaries as planned, and pending the decision for M82, will begin shipping Dev channels again in the near future.

We’re hoping to provide an update in the next week around our future plans for resumption of releases.

What you can do to help

While our release schedule is paused, it’s critical that we keep the trunk/master in a stable, healthy state. This is where you can help:

  • Add the test coverage you’ve always wanted to, but haven’t had the time. Deflake your existing disabled tests would be great too! This helps avoid regressing the trunk, reduces our reliance on manual testing, and derisks our return to schedule.

  • Think some documentation is lacking? Please help work on improving it! Now is a great time to write that design doc or process doc you’ve been dreaming of.

  • In general, please avoid code changes that make merges hard (e.g. large refactors) or require a lot of branch bake time. The more of these we accrue, the harder it will be to get a stable branch and builds.

  • As much as possible, all behavioral changes should be behind (off-by-default) flags. That allows you to land new code, while delaying activating it until we're ready to resume releases.

  • Please use the Canary channel and file/investigate bugs. This is more helpful than ever to ensure trunk/master is healthy and releasable!

We know this may not answer all your questions, especially with regards to work that fundamentally causes a lot of churn. We haven't forgotten about these topics, but for the next few weeks we'd like people to focus on the work above where possible, and be extra cautious about changes that may be destabilizing. Thank you for your patience and understanding in these extraordinary times. 

Jason, on behalf of Chromium Operations

Arvind Murching

Mar 19, 2020, 12:39:27 PM3/19/20
to Chromium-dev
Hi Jason,

Thanks for posting this note, appreciate you keeping the Chromium community informed, and for taking the pause to accommodate remote working given current circumstances!

Can you share an ETA for publishing an updated plan?


John Abd-El-Malek

Mar 19, 2020, 3:24:06 PM3/19/20
to Jason Kersey, chromium-dev
Hi everyone, on behalf of eng-review we wanted to provide some more guidance about what kind of changes should or shouldn’t land on trunk while Chrome is pausing releases and working to ensure stability for our users.

The main objectives are:

1) Keep the trunk stable and reliable, so that once we restart releases we don’t end up with many bugs that delay trunk going to stable.

2) Ensure that we can merge fixes to M80 or M81 when needed.

If we had perfect test coverage 1) wouldn’t need to be stated. However we know that subtle bugs can creep in small or large changes. Ways to decrease the risk include:

  1. Changing code behind a feature or command line flag.

  2. If there’s cleanup work that you see as part of a change but isn’t required, file a bug and fix it when we’re out of this phase.

  3. As always, all code needs automated test coverage. If you’re editing code (whether behind a flag or not) that didn’t have automated tests, now more than ever it’s important to add tests to ensure your CL doesn’t introduce any unintended behavioral change. Take advantage of the code coverage bots to verify this is the case.

For 2) the main concern is that refactoring changes make merges of fixes to the release branch hard or could break things in subtle ways that are hard to catch with tests. Ways to decrease the risk include:

  1. Avoid refactoring changes that aren’t necessary for your team to execute in the near term. This includes things like refactorings for code health rotation, IPC conversions etc…

  2. Consider if the code being refactored has been modified recently. Code with fewer recent modifications is unlikely to have recently added bugs that would require fixing and merging therefore changes in these areas are less likely to disturb critical merges.

  3. Make your refactoring change behavior-free so that it’s easy for reviewers to confirm this. If there’s behavior changes needed, do them in a follow up which would be small and easy to review (see c) above).

Note that the above guidance does not mean you should stop working on feature work provided that the code you're introducing meets the guidelines above. Having said that, different teams may be assessing priorities and choosing to use this time to double down to test automation or other areas. Please check with your TL or manager.

We understand that these guidelines will affect some of your work; we are working towards loosening these requirements as we better understand the constraints we have in resuming releases. Expect further guidance around releases and our plans there in the near future.

If you have any feedback or questions, email us at These guidelines are also in this doc if you want to share it or in case we provide more updates. If there are any major guidance changes we'll update this thread, but for minor clarifications the doc will be updated silently.

Thank you

John, on behalf of chome-eng-review

Chromium Developers mailing list:
View archives, change email options, or unsubscribe:
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Colin Blundell

Mar 20, 2020, 5:07:51 AM3/20/20
to John Abd-El-Malek, Jason Kersey, chromium-dev
This really brings clarity, especially from a reviewing POV. Thank you for putting it together!


Mar 20, 2020, 6:32:17 AM3/20/20
to Colin Blundell, chromium-dev, John Abd-El-Malek, Jason Kersey, Daniel Bratell
Just noting that in case your GOMA solution is not working as well as expected due to working remotely (just guessing here), it might be good to reinstate Jumbo.


Jason Kersey

Mar 21, 2020, 6:08:31 PM3/21/20
to Chromium-dev

Howdy folks,

This is an update on our earlier decision to pause our branch and release schedule. As we adapt our future milestone schedules to the current change in schedule, we have decided to skip the M82 release to ensure we keep users safe and focus all efforts on maintaining stability.

Here are some of the immediate actions based on the above decision:

  • We will abandon current M82 branches, remove infra support, and stop testing/merges to the branches

  • We will not push any new M82 releases to Dev, and we will stop stabilization for Beta

  • We will move Dev channel to M83 asap

  • We will keep Beta channel on M81 until M83 is ready to be promoted 

Once M81 is cleared to release to Stable, we expect to adjust our future milestone schedules, including possibility shifting M83 forward to target an earlier branch and Stable date.  

With the above changes, we will continue to focus on keeping the trunk/master healthy. Please continue supporting and helping on tasks associated with that goal. There are no changes to the existing requests to land safe changes, and avoid risk.


We expect to provide another update next week around our anticipated next steps and timing around releasing M81, and branching for M83. Thanks again for your patience and support.


On Wednesday, March 18, 2020 at 5:23:18 PM UTC-7, Jason Kersey wrote:

Nico Weber

Apr 1, 2020, 2:32:18 PM4/1/20
to Jason Kersey, chromium-dev
Just to bump this up again. If someone sends you a CL that's part of a huge automated code rewrite (e.g. if it says "Uploaded by `git cl split`"), then please -1 that Cl for now.

John Abd-El-Malek

Apr 23, 2020, 1:26:42 PM4/23/20
to chromium-dev, Jason Kersey
Hi everyone, this was sent out internally but I'm repeating it here for non-Googlers (sorry we forgot to do that earlier!).

We are ready to resume regular development activities in the trunk/master, including refactoring. Please continue to be extra careful and responsive in case of any regressions to provide fixes ASAP.

Reply all
Reply to author
0 new messages