breadcrumbs: Issue Tracking > chromium_link: Chromium chromium_os_link: Chromium OS home_link: Home page_name: release-block-guidelines title: Release Block Guidelines title_hdr: |

See also this more recent document.

What are the intents of ReleaseBlock? ReleaseBlock issues are immediately gating the release of the branch (Dev, Beta, Stable). These issues require the highest priority of attention from the engineers assigned (since they are directly on the critical path). They are meant to be used as a tool for program managers to focus engineers to get a Chrome release launched with high standard of quality (e.g. absent critical regressions, stability, build issues, etc...). What aren’t the intents? ReleaseBlock issues are not meant to be a scoping or prioritization tool (we have specific labels and normal processes for each of those, respectively mstone- and pri-). If an issue isn’t getting sufficient attention, it should be escalated to a TPM and/or the priority adjusted accordingly. Making arbitrary issues ReleaseBlockers, when mstone and proper prioritization would otherwise suffice, makes it very hard to see the true critical path of our release cycle.

Best Practices:

  • Nominate blockers liberally, it’s better to catch someone’s attention than to ignore an issue.
    • That said, expect TPMs to say no sometimes.
  • Ask yourself if you would really block a release for this issue, if the answer if no, the next best option is to make sure the priority is set correctly, the issue is assigned, and an mstone label is set.
  • All ReleaseBlock bugs should have owners
  • If you have a request for an out of band (i.e. non-releaseblock) merge, add a Merge-Requested flag and the TPM responsible for the branch will take a look.

Signals of Poor Practices:

  • Assigned a P2/P3 issue as a ReleaseBlocker
    • Explanation:
      • P2/P3 are generally considered nice to have merges
  • Setting a ReleaseBlock label 6 weeks in advance of a branch point.
    • Explanation:
      • It suggests that normal processes for prioritization/ scoping aren’t being followed. In cases where issues are not imminently blocking a release (i.e. 3-6 weeks in advance), such practices dilute the intent of a releaseblock, which literally means, drop what you are doing and work on nothing else. Such calls may be overly disruptive to engineers, and may not be the correct priority call if the issue in question does not need immediate attention.
  • Setting a ReleaseBlock issue w/ out an owner or marking it as Available
    • Explanation:
      • If an issue is really critically urgent it should be assigned right away, we should not wait around for normal triage to determine an owner (i.e. we should not be sitting on these issues).