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.

Sign up for GitHub

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

Jump to bottom

Clarify labeling states on proposed cherrypicks. #23555

Merged
merged 1 commit into from
Apr 1, 2016
Merged

Clarify labeling states on proposed cherrypicks. #23555

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
47 changes: 25 additions & 22 deletions docs/devel/cherry-picks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,29 +40,32 @@ depending on the point in the release cycle.

## Propose a Cherry Pick

### BATCHING: After branching during code slush up to X.X.0
1. Cherrypicks are [managed with labels and milestones](pull-requests.md#release-notes)

Starting with the release-1.2 branch, we shifted to a new cherrypick model
where the branch 'OWNERS' cherry pick batches of patches into the branch
to control the order and also vet what is or is not cherrypicked to a branch.
1. All label/milestone accounting happens on PRs on master. There's nothing to do on PRs targeted to the release branches.
1. When you want a PR to be merged to the release branch, make the following label changes to the **master** branch PR:

Contributors that want to include a cherrypick for a branch should label
their PR with the `cherrypick-candidate` label **AND** mark it
with the appropriate milestone (or the bot will unlabel it).
* Remove release-note-label-needed
* Add an appropriate release-note-(!label-needed) label
* Add an appropriate milestone
* Add the `cherrypick-candidate` label

These cherrypick-candidate's will be triaged, batched up and submitted
to the release branch by the branch OWNERS.
### How do cherrypick-candidates make it to the release branch?

There is an [issue](https://github.com/kubernetes/kubernetes/issues/23347) open to automate this new procedure.
1. **BATCHING:** After a branch is first created and before the X.Y.0 release
* Branch owners review the list of `cherrypick-candidate` labeled PRs.
* PRs batched up and merged to the release branch get a `cherrypick-approved` label and lose the `cherrypick-candidate` label.
* PRs that won't be merged to the release branch, lose the `cherrypick-candidate` label.

### INDIVIDUAL CHERRYPICKS: Post X.X.0
1. **INDIVIDUAL CHERRYPICKS:** After the first X.Y.0 on a branch
* Run the cherry pick script. This example applies a master branch PR #98765 to the remote branch `upstream/release-3.14`:
`hack/cherry_pick_pull.sh upstream/release-3.14 98765`
* Your cherrypick PR (targeted to the branch) will immediately get the
`do-not-merge` label. The branch owner will triage PRs targeted to
the branch and label the ones to be merged by applying the `lgtm`
label.

```sh
hack/cherry_pick_pull.sh upstream/release-3.14 98765
```

This will walk you through the steps to propose an automated cherry pick of pull
#98765 for remote branch `upstream/release-3.14`.
There is an [issue](https://github.com/kubernetes/kubernetes/issues/23347) open tracking the tool to automate the batching procedure.

#### Cherrypicking a doc change

Expand All @@ -71,14 +74,14 @@ If you are cherrypicking a change which adds a doc, then you also need to run
Ideally, just running `hack/cherry_pick_pull.sh` should be enough, but we are not there
yet: [#18861](https://github.com/kubernetes/kubernetes/issues/18861)

To cherrypick PR 123456 to release-1.2, run the following commands after running `hack/cherry_pick_pull.sh` and before merging the PR:
To cherrypick PR 123456 to release-3.14, run the following commands after running `hack/cherry_pick_pull.sh` and before merging the PR:

```
$ git checkout -b automated-cherry-pick-of-#123456-upstream-release-1.2
origin/automated-cherry-pick-of-#123456-upstream-release-1.2
$ ./build/versionize-docs.sh release-1.2
$ git checkout -b automated-cherry-pick-of-#123456-upstream-release-3.14
origin/automated-cherry-pick-of-#123456-upstream-release-3.14
$ ./build/versionize-docs.sh release-3.14
$ git commit -a -m "Running versionize docs"
$ git push origin automated-cherry-pick-of-#123456-upstream-release-1.2
$ git push origin automated-cherry-pick-of-#123456-upstream-release-3.14
```

## Cherry Pick Review
Expand Down
16 changes: 6 additions & 10 deletions docs/devel/pull-requests.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,16 +73,12 @@ The following will save time for both you and your reviewer:

## Release Notes

All pull requests are initiated with a `needs-release-note` label.
There are many `release-note-*` label options, including `release-note-none`.
If your PR does not require any visibility at release time, you may use a
`release-note-none` label. Otherwise, please choose a `release-note-*` label
that fits your PR.

Additionally, `release-note-none` is not allowed on PRs on release branches.

Finally, ensure your PR title is the release note you want published at relase
time.
1. Your PR title is the **release note** you want published at release time.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Title is insufficient and in many cases inappropriate.

Compare:
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#other-notable-improvements

and:
https://github.com/kubernetes/kubernetes/releases/tag/v1.1.2

I want the former, not the latter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 2 different kinds of releases. There are major new branch releases and then there's everything else (alpha, beta, patch). Automated release notes are not meant to target the major new branch releases (as the example you gave). No amount of automation is going to construct lengthy, detailed and easy to read descriptions that were hand crafted as in the example of 1.2.0.

As I pointed out in the proposal, the automation should aim to provide automated release notes for every kind of release except the major new branch kind and for those the automation is merely bootstrapping the release notes so that the release owner can make them look like the carefully constructed release detail in your 1.2.0 example.

Another thing to consider is the workflow and how frictionless release note collection is to contributors. The PR title is something people are used to providing already and is the current workflow. Asking them to further be sure to construct a parsable, lengthy release note somewhere in the body of each PR is really putting a burden on folks, IMO. And chances are they won't get it right and there will be a significant amount of editing anyway.
Furthermore, there's no built-in way (using git or github) to validate the body by looking for a tag and a description, though I suppose a custom bot could be designed.

The current solution gets us to ~90% with automated notes for alpha, beta, minor and bootstrapping of major releases. If you could say the additional work of asking contributors to fill in a "good release note" in the body somewhere, parsing it, extracting and formatting it gets us another 5%, I'm not sure that's worth it and like I said before it could end up creating more work in the end for the branch owner to pull apart the mess of title + additional body contents/formatting.

If we do want to investigate this, it's certainly worth it's own issue. There will be lots of work to do to make that happen and it will take time to implement and test.

1. Release note labels are only needed on master branch PRs.
1. All pull requests are initiated with a `release-note-label-needed` label.
1. For a PR to be ready to merge, the `release-note-label-needed` label must be removed and one of the other `release-note-*` labels must be added.
1. `release-note-none` is a valid option if the PR does not need to be mentioned
at release time.

## Visual overview

Expand Down