search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.98k stars 17.67k forks source link

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

Open bradfitz opened 5 years ago

bradfitz commented 5 years ago

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

ianlancetaylor commented 5 years ago

Thanks.

dmitshur commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.