Cures for functional regressions to the default shipping experience of Chrome

Important note about Risk: Because of the early phase of the branch, we are generally a little less risk averse at this point in the project (we have to extend a bit of trust (which we validate) to our engineers, that they are requesting reasonable items

Merges that we will accept in this phase

Must have at least been on the Canary channel for 1 day, and verified to have been fixed.

ReleaseBlock:Dev issues

Stability issues

Cures for critical regressions

Patches to turn off/ disable features

Small refinements/fixes

Important notes about what is acceptable:

Minor/ low risk patches that cure defects in the product that would harm the default user experience

Examples of things we’d reject: Major changes to behavior, UI, features, a change to a feature that was behind a flag, etc...

Merges we will reject (i.e. things we should Merge-Reject)

Changes to strings (i.e. .grd changes)

At branch point, we are frozen from a localization perspective

Building out a feature that isn't complete on the branch (a hint of this is when there are more than a couple of requests for a single feature)

Work for features that are behind flags or not enabled by default (e.g. building out a Finch experiment)

Some logic tests to apply:

Are we shipping a product that is of lower quality than the previous release?

Does this patch have a material benefit to a group of end users?

What size of the affected group?

Is the risk (to all of our Beta channel users) of accepting this patch worth the benefit to the affected user base?

When do we move to the next phase?

Once we promote the release to the Beta channel

Phase 3: The Push to Stable

Key Objective: Get a working release of Chrome that meets or exceeds the quality level of the existing stable channel.

What this means in practice:

We are looking to cure any remaining:

Security issues

Stability issues

Critical regressions

Merges that we will accept

Should have at least been on a Dev channel for 1 day, and verified to have been fixed

ReleaseBlock-Stable issues that fit the category of Security/Stability/Critical Regressions

Important Note about Risk: Risk tolerance in this phase is greatly diminished from when we are in Dev (and diminishes as we approach our stable launch date). We need to be open to patches, but there needs to be a very clear ROI to the overall user population

Merges that we will reject

Everything at this point should be closely reviewed on a case by case basis, but as a general guideline anything that’s not a stability, security, or critical regression at this point should be rejected

Should have at least been on a Dev or Beta channel for 1 day, and verified to have been fixed

Only very critical ReleaseBlock-Stable issues that fit the category of Security/Stability/Critical Regressions

Important Note about Risk:

Our tolerance for merges is at its lowest at this point in the cycle. Every change that lands needs to be safe and must have a very specific purpose.

Under normal conditions we try to bucket these merges into 1-2 post stable updates. That said, depending on the urgency/ nature of the issues, we may need to do a special release (e.g. a critical issues that affects a non-trivial number of users).