4-week release: dry run?

[Arvind Murching]

Hi,

What are your thoughts on doing a dry run of the system that will produce releases every 4 weeks, to clean the process pipes as it were?

If there is such a plan, we (Microsoft Edge) would love to participate.

Thanks

Arvind

[Alex Mineer]

While we might plan a more formal exercise later this year, to this point our biggest focus has been around fixing release blocking issues quickly, since letting them sit idle until later in the release cycle risks fixes being more complicated than anticipated, new issues accidentally introduced, etc - which puts releases at risk, especially in a shorter release cycle.  We've been beta testing SLOs for release blockers internally to help address this, and we're hoping to extend those project-wide in the coming months - I'd be happy to share what those look like if you'd like to try to hit the same targets.  If we plan other exercises, I'll be sure to circle back here.

Cheers,

Alex

--
You received this message because you are subscribed to the Google Groups "branches" group.
To unsubscribe from this group and stop receiving emails from it, send an email to branches+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/branches/BN8PR00MB0563E8BB82FF8B6E529A377CAA909%40BN8PR00MB0563.namprd00.prod.outlook.com.

[Arvind Murching]

Hi Alex, yes, it would help to have visibility into the SLOs you’re practicing with.

 

Thanks

Arvind

[Alex Mineer]

I'll update this page in the future to include this data, but in the interest of time, we have two categories of blockers and two types of SLOs:

Blocker categories:

 - Urgent blockers are blockers that are tied to a release scheduled to ship in a week or less (e.g. a dev blocker for M91 when M91 is currently shipping to canary / dev, a stable blocker for M90 when the M90 stable release date is less than a week away)

 - Standard blockers are all blockers that aren't urgent

SLO types:

 - Comment SLO: How often the assignee needs to comment on the bug (recurring), measured from time of last comment (or when issue was assigned if no comment present)

 - Fix SLO: How long the assignee has to fix the bug, measured from time issue was assigned

For urgent blockers, we want to see comments every business day, and fixes within two business days; for standard blockers, comments every other business day and fixes within five business days.  We feel folks should always be able to meet the comment SLO, and folks should usually be able to meet the fix SLO, though we acknowledge the fix SLO is sometimes tough to meet depending on the issue at hand, it's more meant to encourage folks to revert quickly where viable rather than fix-forward more slowly.

I can circle back here when the doc linked above is updated and if / when we have tooling to help query and measure these available for public consumption.

Cheers,

Alex