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

Sync up all release note related docs with the latest process/procedures #23939

Merged
merged 1 commit into from
Apr 8, 2016
Merged

Sync up all release note related docs with the latest process/procedures #23939

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
5 changes: 3 additions & 2 deletions docs/devel/cherry-picks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,14 +41,15 @@ depending on the point in the release cycle.
## Propose a Cherry Pick

1. Cherrypicks are [managed with labels and milestones](pull-requests.md#release-notes)

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:

* Remove release-note-label-needed
* Add an appropriate release-note-(!label-needed) label
* Add an appropriate milestone
* Add the `cherrypick-candidate` label
* The PR title is the **release note** you want published at release time and
note that PR titles are mutable and should reflect a release note
friendly message for any `release-note-*` labeled PRs.

### How do cherrypick-candidates make it to the release branch?

Expand Down
27 changes: 25 additions & 2 deletions docs/devel/pull-requests.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,7 @@ Documentation for other releases can be found at
- [Life of a Pull Request](#life-of-a-pull-request)
- [Before sending a pull request](#before-sending-a-pull-request)
- [Release Notes](#release-notes)
- [Reviewing pre-release notes](#reviewing-pre-release-notes)
- [Visual overview](#visual-overview)
- [Other notes](#other-notes)
- [Automation](#automation)
Expand Down Expand Up @@ -73,12 +74,34 @@ The following will save time for both you and your reviewer:

## Release Notes

1. Your PR title is the **release note** you want published at release time.
1. Release note labels are only needed on master branch PRs.
This section applies only to pull requests on the master branch.

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.
1. The PR title is the **release note** you want published at release time.
* NOTE: PR titles are mutable and should reflect a release note friendly
message for any `release-note-*` labeled PRs.

The only exception to these rules is when a PR is not a cherry-pick and is
Copy link
Contributor

Choose a reason for hiding this comment

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

https://github.com/kubernetes/contrib/pull/738/files#diff-7294a858e5f70293980043d7fe211686R64 is a munger that should enforce this (as best we can).....

targeted directly to the non-master branch. In this case, a `release-note-*`
label is optional (and not enforced).

### Reviewing pre-release notes

**NOTE: THIS TOOLING IS NOT YET AVAILABLE, BUT COMING SOON!**

At any time, you can see what the release notes will look like on any branch.

```
$ git pull https://github.com/kubernetes/release
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this repo is currently empty, should we wait to put in instructions until the tool actually exists?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Qualified with COMING SOON. I'm attempting to optimize the fact that every little change to a doc seems to take days or longer due to long test/queue cycles coupled with flakes and retries... sigh.

$ RELNOTES=$PWD/release/relnotes
$ cd /to/your/kubernetes/repo
$ $RELNOTES -man # for details on how to use the tool
# Show release notes from the last release on a branch to HEAD
$ $RELNOTES --raw --branch=master
```

## Visual overview

Expand Down
17 changes: 11 additions & 6 deletions docs/proposals/release-notes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ Documentation for other releases can be found at
# Kubernetes Release Notes

[djmm@google.com](mailto:djmm@google.com)<BR>
Last Updated: 2016-3-25
Last Updated: 2016-04-06

<!-- BEGIN MUNGE: GENERATED_TOC -->

Expand Down Expand Up @@ -115,14 +115,19 @@ hundreds of entries. The goal is to highlight the major changes for a release.

The munger/bot option fits most cleanly into the existing workflow.

The design will include:
All `release-note-*` labeling is managed on the master branch PR only.
No `release-note-*` labels are needed on cherry-pick PRs and no information
will be collected from that cherry-pick PR.

The only exception to this rule is when a PR is not a cherry-pick and is
targeted directly to the non-master branch. In this case, a `release-note-*`
label is optional (and not enforced).

1. New labels added to github: `release-note-none`, maybe others for new release note categories - see Layout section below
1. A [new munger](https://github.com/kubernetes/kubernetes/issues/23409) that will:
* Initiate a `release-note-needed` label on all new PRs
* Block merge by the submit queue on all PRs labeled as `release-note-needed`
* Auto-remove `release-note-needed` when one of the release-note-\* labels is added
* Special case for cherry-picked/branch PRs, release-note-none is not allowed
* Add a `release-note-label-needed` label to all new master branch PRs
* Block merge by the submit queue on all PRs labeled as `release-note-label-needed`
* Auto-remove `release-note-label-needed` when one of the `release-note-*` labels is added

## Publishing Design

Expand Down