Ownership for Approvals
Guidelines for ApprovalsPhase 1: Branch DayKey Objective: Get a release to the Dev channel that we can validate for fitness as a branch point. What that means in practice: What merges we accept: Merges that we will reject: When do we move to the next phase?
Phase 2: The Push to BetaKey Objective: Refine our Dev channel to get it Beta ready (as quickly as reasonably possible, to return the Dev channel back to trunk based builds), addressing critical regressions (stability, performance, behavior, etc...). What that means in practice: There are a few parallel objectives in this phase: Clear Stability Issues Clear ReleaseBlock-Beta issues Disable features/functionality that aren't ready to ship 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
Merges we will reject (i.e. things we should Merge-Reject) Changes to strings (i.e. .grd changes) 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?
Phase 3: The Push to StableKey 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
When do we exit this phase?
Phase 4: Post Stable
|
|