kubernetes / sig-release

Repo for SIG release

SIG Release

Charter

The charter defines the scope and governance of the Release Special Interest Group.

Join us!

If you are new to the Kubernetes community and would like to start contributing, you can check out the "Getting Started" guide for Kubernetes contributors. Below are some more links specifically to sig-release to get in touch with us.

• Slack
• Mailing list
• Open Issues / PRs
• Meeting agenda and notes

Roadmap and Vision

SIG Release maintains their own Roadmap and Vision in a dedicated document.

Release Team

Several of the responsibilities of SIG Release are discharged by the Release Team, a subproject of SIG Release. Explicit details on each of the roles can be found in the Release Team subproject directory.

Processes

The following high-level descriptions of SIG Release processes should provide a general overview about the work we're doing:

• Release Notes
• Versioning

sig-release's Issues

Release v1.10.1 Tracking

Kubernetes v1.10.1 has been built and pushed.

The release notes have been updated in CHANGELOG-1.10.md with a pointer to it on github.
cc @kubernetes/sig-release-members

Address markdown format symbols in PR release note block?

Some PRs' release notes have markdown format symbols (e.g., -, *), this leads to bad format in the CHANGELOG (see 1.9 changelog).

kubernetes/kubernetes#54175
kubernetes/kubernetes#52792
kubernetes/kubernetes#53043

We may not avoid PR authors to use such symbols, so should we address this case in the release note tool? @roycaihw

/cc @enisoc @david-mcmahon @Bradamant3

Milestone automation for PRs

@spiffxp @marun @jberkus

This is a tracker to discuss extending some form of the milestone automation we have for issues to apply to pull requests.

The milestone has a different meaning on issues and PRs during code freeze:

• For issues, it means, "This is a release-blocking bug."
• For PRs, it means, "This code change is ok to make during freeze."

Note that these criteria can be independent: A PR might be allowed during freeze if it's approved for the milestone, even if it has no issue (/approve no-issue). Also, a PR associated with an issue that's approved for the milestone is not necessarily making a code change that's permissible during freeze.

For this reason, I propose applying milestone automation separately to issues and PRs, without trying to cross-reference the milestone status of issues linked from PRs. SIGs will need to separately approve the problem (issue) and the particular solution (PR) for the milestone.

The automation for PRs will help us do things like remove everything but release-blockers (priority/critical-urgent) from the milestone upon entering code freeze. It also would help communicate milestone requirements to PR authors during slush and freeze.

Define and fill Release Notes Coordinator role

This role needs to be fully defined by SIG-Release.

v1.9.0

According to the timeline, we should cut v1.9.0 on Wed, Dec 13

This is a tracker for burning down release-blocking test failures and recording release cut status.

Fill Bug Tracking release role

We need to fill the bug tracking release role.

Automate deb/rpm publishing

This is an action item issue to make sure anago takes care of pushing debs/rpms in v1.8
Now it's a really painful process to have to ping various Googlers to push the packages manually

The proposed way of fixing this is by making a new GCS bucket that is set up as a deb/rpm repo.
It must maintain the structure of the current apt.kubernetes.io repo.

Then, in the release process, packages will be built and published by just pushing to GCS.

It's also a lot easier to manage ACLs with a GCS bucket compared to the Google-internal stuff we're currently depending on. (Where the source code/tools used are confidential)

For converting .deb packages to something pushable to GCS we can use https://github.com/spotify/debify
I don't know what's the best way to create a yum repo, but will look for something useful

cc @david-mcmahon @ixdy @jdumars @mikedanese @pipejakob @wojtek-t

Make kind, sig labels auto-copy to PRs

Due to the changes from PR milestone automation (#26), we now have a hard requirement that kind, sig and priority labels need to be populated for PRs. I propose that we add to our automation to make that easy, specifically:

If a PR is linked to an issue, and the PR has no kind, sig, or priority labels, the kind, sig and priority labels from the linked issue should be copied to the PR automatically.

Obstacle: Github's notion of a PR being linked to an issue is rather loose; basically, if the PR is mentioned at all in the issue. This could lead to PRs being tagged that are only mentioned tangentally. Is there a useful way around this?

Setup merge automation for this repo

Use an OWNERS file, /approve, /lgtm to allow people to merge PR's into this repo:

• If there isn't an OWNERS file, create one and populate it with people who already have write access to this repo
• Configure prow to turn on the "approval" plugin for this repo
• Configure prow/tide to include this repo in the tide query
• Remove direct write access to this repo by all but the @kubernetes/sig-release-admins team (this is something I don't have the privileges to do)

/assign

[1.9] Code Freeze

According to the timeline, we should start Code Freeze on Wed, Nov 22 (after 3pm PST).

As far as I know, this involves the following:

• Update submit queue config to set additional-required-labels.
  • Require both status/approved-for-milestone and priority/critical-urgent labels.
• Update milestone bot config to set milestone-modes and milestone-freeze-date.
  • Set mode for v1.9 to freeze.
  • Set freeze date to TBD.

@marun Does that look right to you?

cc @jberkus

Create release-1.9 branch

According to the timeline, we should create the release-1.9 branch and start setting up test infra on Thu Nov 16.

@dashpole You can create the branch with anago, and then we'll need you to run branchff every day to keep it up to date. Let me or @david-mcmahon know if you have any questions.

@BenTheElder Do you have access to any instructions from previous release test-infra leads on what needs to be set up?

Add new @k8s-release-robot permissions on k/sig-release and k/kubernetes

A new @k8s-release-robot user has been added to the project in order to facilitate the transfer of Kubernetes software release functions from Googlers (creating releases only on a desktop) to both Googler and non-Googler Kubernetes project contributors creating releases via https://cloud.google.com/container-builder.

Basic doc on functionality can be found here in the kubernetes/release repo.

In order for @k8s-release-robot to prepare and deliver releases via GCB, it must have write access to kubernetes/sig-release in order to assign owners and write labels to the release tracking issue created during a release and it must have 'repo admin' rights on kubernetes/kubernetes in order to push branches, tags and source code artifacts (CHANGELOG*.md, swagger.json) during releases. Essentially membership in @Kubernetes/kubernetes-release-managers.

Subproject release versioning eg. Federation!

This issue is to pick up some debate/pointers from folks with more experience in k8s and its maintenance about the probable release versioning that is ideal for projects which have been separated out into their own github repos with the intention of independent maintenance and release.
As the project until now was maintained and released as part of k8s releases, there are 2 alternatives to use:

• Follow k8s versioning and its releases (1.9 onwards).
• Start with a new versioning considering this release as 1.0-alpha/beta.0 (or something else).

Both have some pros and cons and there is no clear precedent.
We have an example of client-go, which maintains its own versioning scheme and publishes a compatibility matrix (probably not a very good example as its only a library for clients). We also have an example of tools like kubeadm and kubectl (which probably are candidates which will be maintained externally) but haven't reached there yet and the code and binaries still map to k8s core. It makes lot of sense to follow some scheme which by version itself can provide enough info to the reader about its compatibility with any given k8s release.

I initiated a brief doc a while ago to collect comments. This issue is an attempt to share that will a wider audience and/or to collect feedback/suggestions for the same here. Please point me in the right direction if this is not the place for this topic.

cc @kubernetes/sig-multicluster-misc

Release v1.7.16 Tracking

Kubernetes v1.7.16 has been built and pushed.

The release notes have been updated in CHANGELOG-1.7.md with a pointer to it on github.
cc @kubernetes/sig-release-members

v1.9.0-beta.1

According to the timeline, we should cut v1.9.0-beta.1 on Wed, Nov 29

This is a tracker for burning down release-blocking test failures and recording release cut status.

1.10 Issue Burndown

This issue is for status updates on 1.10 issues for release tracking.

[job failure] gci-gke-serial

wrong repo

v1.9.0-alpha.3

According to the timeline, we should cut v1.9.0-alpha.3 on Wed, Nov 15.

This is a tracker for burning down release-blocking test failures and recording release cut status.

Fill Patch Manager release role

The open patch manager role needs to be filled by a Google engineer due to constraints in the CI implementation.

[1.9] Code Slush

According to the timeline, we should start Code Slush on Mon, Nov 20 (after 3pm PST).

As far as I know, this involves the following:

• Update submit queue config to set do-not-merge-milestones and additional-required-labels.
  • Block empty milestone, as well as all milestones > v1.9.
  • Require status/approved-for-milestone label.
• Update milestone bot config to set milestone-modes and milestone-freeze-date.
  • Set mode for v1.9 to slush.
  • Set freeze date to Wed, Nov 22.

@marun Does that look right to you?

cc @jberkus

Schedule recurring release team meetings

We need a regular meeting cadence for the core 1.8 release team separate from SIG-Release.

Create a Release calendar

I think it'd be pretty cool to have a Release calendar, which tracks the timeline laid out here.
Ideally it lives outside of the sig-release calendar and survives across releases.

Thoughts @jberkus ?

Fill Test Signal Lead release role

We need to fill the testing lead role.

Finalize Release roles: Lead/secondary

Release role recruitment has been underway for a few weeks, and the release lead and secondary need to be finalized.

v1.9.0-alpha.2

According to the planned timeline, we should cut alpha.2 on Wed, Nov 1.

@dashpole Can you try a mock build with anago to start getting your workstation set up? Let me know if you run into any trouble.

@spiffxp @detiber How far from green are we on release-master-blocking tests? Can we at least have owners for all the failures by a week from now?

MILESTONENOTIFIER comment is not so clear

It says: kubernetes/kubernetes#55065 (comment)

Note: This pull request is marked as priority/critical-urgent, and must be updated every 1 day during code freeze.
Example update:
ACK. In progress
ETA: DD/MM/YYYY
Risks: Complicated fix required

For this part:
Example update:
[1]

ACK. In progress
ETA: DD/MM/YYYY
Risks: Complicated fix required

What should the PR author do to update? Just commenting something as [1] shows or commenting anything would be OK?

/cc @enisoc @marun

Migrate the release-1.x dirs out of kubernetes/features to here

It's been confusing to have to bounce between multiple repos to get details about the release and the release team.

If we can't outright remove the files in kubernetes/features we should at least tombstone them as links to copies that exist here.

No explicit due date or priority on this, it's a thing I'm interested in but I'd be just as happy if someone other than me got this done.

v1.9.0-beta.2

According to the timeline, we should cut v1.9.0-beta.2 on Wed, Dec 6.

However, we might consider cutting on Mon, Dec 4, if the exception requests granted until Dec 1 have merged.

Define criteria for a job to be release-blocking

This is a tracker for writing a concrete policy for deciding whether a given job should be release-blocking.

v1.8.0-alpha.3 release

We are planning an alpha release on 8/23 with the following dependencies:

• Interim branch manager staffed from Google
• All master-blocking tests are green
• No release-blocking issues

I will report status on this issue as we move forward.

Need a verify script / test to confirm that new vendored dependencies have acceptable OSS licenses

Example: No LICENSE file:

https://github.com/reconquest/loreley

Define and fill "Marketing Manager release role"

This role was identified as a key missing element in the 1.7 Release retrospective. We need to define the role, accountabilities, and activities ASAP as well as find someone to fill the role.

Update [1.8 release team][] with shadow release lead.

Initially opened by @calebamiles at https://github.com/kubernetes/sig-release/projects/2

Code freeze - Friday, September 1st

Code freeze will be enforced by EOD September first. Activities related to the freeze will be documented here.

Extract docs from `kubernetes/community`

We should start collecting the documents sprinkled in kubernetes/community which should be maintained by SIG Release

Standard SIG metadata

Who are the SIG leads? What is the mailing list? When are meetings? Where are the notes and recordings?

This is all missing from here and the community repo. See kubernetes/community#891.

Generate hierarchical release notes

There is an effort underway to generate release notes from PRs, grouped by SIG and area labels. As the release team, we should engage with them to help test the tool and give feedback.

kubernetes/release#434
kubernetes/release#435

Fill Docs Manager release role

We need to fill the documentation manager role.

Fill Test Infrastructure release role

Volunteer needed from Google to fill the Test Infrastructure role.

Document Features role / responsibilities

As a Release Team member shadowing the Features Lead role, it should be my responsibility to explicitly document and / or revise documentation that corresponds to that role.

Documentation should delineate:

• Role overview
• Responsibilities
• Access requirements

Here's a good example of what the docs might look like.

We should also then cross-link that documentation to the features repo.

/cc @idvoretskyi
/assign

Finalize 1.8 schedule

There is an outstanding PR to finalize the release timeline, to be discussed and merged Friday, July 21st at 21:00 UTC. Outstanding question is how best to move the final version into this repository.

New release- branches with no changes have that commit double-tagged

When the release-1.10 branch was created, we ended up in a new situation where the branch point commit was tagged with both the master branch (alpha) and release branch tags (beta). This was due to a recent commit to the tooling which excluded a change to the branch at branch time which provided the opportunity to then tag the branch at branch-point + 1.

The immediate remedy here to set the master branch straight so it is 'git describe'ing correctly was to remove the (beta) tag from the commit.

Proposal 1:

• Submit a change to the release-1.10 branch solely for the purposes of tagging
• Tag the release-1.10 branch with v1.10.0-beta.0
• Update anago to make a change to the release branch at branch time so it can be tagged

Proposal 2:

• Wait for the first branch fast-forward and tag v1.10-0-beta.0 at branch-point + 1
• Update anago to no longer add a new tag to the master at branch time
• Update branchff to take an option to manually to tag the master branch with the new tag after the "last" fast-forward is done. Humans required. Fragile. Scary.

cc @calebamiles @enisoc @kubernetes/test-infra-maintainers @jdumars
ref kubernetes/kubernetes#59895

Test Tracking Issue

Kubernetes has been built and pushed.

The release notes have been updated in CHANGELOG-1.11.md with a pointer to it on github.

Move existing documentation from community/sig-release here

We need to ensure historical documentation is moved here for context and ease of use. This process needs to be non-destructive since this change has not been radiated to the larger community.

Add initial structure to the repository

One of the primary purposes of this SIG repository is to add more structure than previously existed in the kubernetes/community repo. I propose the following directory structure for the repo

├── LICENSE
├── members.md
├── README.md
├── release-process-documentation
│   ├── documentation-guides
│   │   ├── update-release-docs.md
│   │   └── updating-docs-for-feature-changes.md
│   └── github-guides
├── releases
│   ├── release-1.2
│   ├── release-1.3
│   ├── release-1.4
│   ├── release-1.5
│   ├── release-1.6
│   └── release-1.7
├── security-release-process-documentation
│   └── security-release-process.md
└── ephemera
    ├── cherry-picks.md
    ├── issues.md
    ├── patch-release-manager.md
    ├── README.md
    ├── scalability-validation.md
    └── testing.md

where

• release-process-documentation stores process docs for the release team and the community
• releases contains historical information about previous releases such as the team list and the release notes draft
• security-release-process-documentation provides quick access to information about our security release process
• ephemera is a staging directory which should be generally empty

[1.9] Feature Freeze

According to the proposed schedule, feature freeze is Fri, Oct 27.

I want to send a reminder to k8s-dev soon, but I wanted to check if we're asking for anything different this cycle.

@idvoretskyi Do you require anything at feature freeze other than that the issues are populated in the features repo?

@Bradamant3 There's something in the proposed schedule about "release talking points" and "sig themes" being due at feature freeze time. Can you elaborate on what we need the SIGs to provide?

[1.9] Issue Burndown

This is a tracker for status updates on 1.9 issue burndown.

[1.9] Lift code freeze

I propose that we lift code freeze on Wed, Dec 13. We expect all the current PRs in the milestone to merge before then.

This will involve undoing the submit queue config from #32.

However, we will maintain the milestone bot config in freeze mode until the 1.9.0 release goes out.

cc @marun @jberkus @spiffxp

Kubernetes v1.10.0 release tar is missing.

We don't have release tar attached in the v1.10.0 release page https://github.com/kubernetes/kubernetes/releases/tag/v1.10.0.

[1.9] Set due dates for docs/relnotes/marketing dependencies

@zacharysarah @Bradamant3 @nwoods3

While cleaning up the release timeline, I only kept items I understand -- mostly code/build-related.

I'd like help from the docs/relnotes/marketing leads to repopulate and document deadlines for things you need from other teams (devs, SIGs, etc.).

Here are some of the things that were previously listed in the timeline that I didn't understand well enough to commit to:

• Release talking points draft due
• SIG themes due in relnotes draft
• First draft of feature related release notes due
• Blog post draft for release team review
• Final draft of feature related release notes due
• Finalize release talking points

I'd like to clarify what deliverable is needed, and who is responsible for delivering it. For example, who writes the release talking points? If it's something the release team does, what do we need from SIGs before we can get it done?