Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: issues: distinguish "blocks beta/rc" from "blocks final release" #33135

Open
bcmills opened this issue Jul 16, 2019 · 1 comment
Open

proposal: issues: distinguish "blocks beta/rc" from "blocks final release" #33135

bcmills opened this issue Jul 16, 2019 · 1 comment

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Jul 16, 2019

When we (@golang/osp-team) triage the issues labeled with release-blocker prior to a release, we often end up sorting them into a finer granularity:

  • “blocking the next beta” (issues that will need broad testing before the release),
  • “blocking the release candidate” (known regressions with limited impact and clear testing steps),
  • “blocking the final release” (documentation, certain kinds of test flakiness).

We end up repeating that classification for each pre-release build, and we spend time discussing the classifications when they could often be made by smaller numbers of people ahead of time.

Furthermore, it's probably useful for folks in the community to be able to see that classification, so that they can set expectations appropriately (and so that they can point out issues that might need more testing than we thought).


I propose that we do one of the following:

a. Create milestones for each pre-release (Go1.13-beta.1, Go1.13-rc.1, and so on).

  • These pre-releases are conceptually before the main miletone (Go1.13), so a release-blocker on Go1.13 would indicate the “blocking the final release” category.

b. Or, create labels for each pre-release (next-beta, next-rc), with the expectation of zero next-beta issues open when we cut a beta release and zero next-rc issues open for a given milestone when we cut the corresponding pre-release for that milestone.

  • We would need to decide whether to have GopherBot ensure that next-* issues are also labeled release-blocker, or have GopherBot remove the release-blocker label as redundant.
@gopherbot gopherbot added this to the Proposal milestone Jul 16, 2019
@gopherbot gopherbot added the Proposal label Jul 16, 2019
@rsc rsc changed the title proposal: meta: add milestone(s) or labels for pre-release blockers proposal: issues: distinguish "blocks beta/rc" from "blocks final release" Oct 9, 2019
@rsc
Copy link
Contributor

@rsc rsc commented Oct 9, 2019

@andybons believes that our increased attention to the release scheduling process may make this less of an issue, and that we should revisit this after the Go 1.14 release, in light of how well Go 1.14 worked.

Putting on hold for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.