Skip to content

release: improve or scrutinize release-blocker label usage

Created by: coury-clark

Currently we have a label release-blocker that can be applied to a PR that will cause the release tool to output blocking issues for a release. Our handbook specifies very few scenarios in which a release is to be blocked; however, during the 3.37 release there were multiple usages of the release-blocker label that did not fit within these guidelines. Additionally, the label was applied days before the release for PRs that were not yet merged, making the release captain have to chase down the teams (one of which was entirely in a different timezone) to understand what was going on.

I think we should revisit this process holistically.

  1. It's useful to be able to signal to a captain that there is potentially a blocking issue; however, these should be resolved before the release cut, not after. Technically this would also be against the handbook policy.
  2. A release captain should be responsible for performing the release, but should not have to be responsible for shepherding teams to remove this label