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

x/build/cmd/release: check for unmerged CLs before release #30422

Open
bradfitz opened this issue Feb 26, 2019 · 4 comments
Open

x/build/cmd/release: check for unmerged CLs before release #30422

bradfitz opened this issue Feb 26, 2019 · 4 comments
Milestone

Comments

@bradfitz
Copy link
Member

@bradfitz bradfitz commented Feb 26, 2019

We just shipped Go 1.12 without merging https://go-review.googlesource.com/c/go/+/163078

Let's make the cmd/release tool query Gerrit for, e.g.

branch:release-branch.go1.12 project:go is:open

And error out if any CLs are open on the branch we're trying to make a release for. There could be an override, like --ignore-cls=163078,162172, explicitly listing numbers, so people can't ignore it with some standard e.g. --force flag that makes its way into some release documentation that's copy/pasted without thinking about what it does.

/cc @dmitshur @andybons @ianlancetaylor @katiehockman @FiloSottile

@bradfitz bradfitz added the NeedsFix label Feb 26, 2019
@bradfitz bradfitz added this to the Go1.13 milestone Feb 26, 2019
@gopherbot gopherbot added the Builders label Feb 26, 2019
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 27, 2019

Thanks.

@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Feb 27, 2019

Let's make the cmd/release tool query Gerrit for, e.g. branch:release-branch.go1.12 project:go is:open And error out if any CLs are open on the branch we're trying to make a release for.

Are you suggesting doing this for 1.x releases only, or 1.x.y ones too?

Should we take any consideration for issues, e.g., ones with CherryPickApproved labels? Is the reason to limit this to CLs is because it's a higher priority place to start, or is there a reason issues shouldn't be involved for this purpose?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 27, 2019

Issues marked for a release should certainly be reviewed. I hope that already happens. But CLs are a higher priority in general, because we only cherry pick CLs that we're pretty sure should go onto the release branch. It should be quick to either submit or abandon all such CLs, and it will avoid shipping a release without a fix that was expected to be in it.

@bradfitz

This comment has been minimized.

Copy link
Member Author

@bradfitz bradfitz commented Feb 27, 2019

Are you suggesting doing this for 1.x releases only, or 1.x.y ones too?

Both.

Should we take any consideration for issues, e.g., ones with CherryPickApproved labels?

Yes, I meant to add a paragraph that we should also do this for GitHub issues too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.