Skip to content

Latest commit

 

History

History
230 lines (173 loc) · 12.9 KB

README.md

File metadata and controls

230 lines (173 loc) · 12.9 KB
Raw

Kubernetes Release Team

Overview

The Kubernetes Release Team is embedded within SIG Release and is responsible for the day to day work required to successfully release while the SIG at large is focused on the continued improvement of the release process. Historically the Release Manager (previously Release Czar) and later Release Team has assumed the following responsibilities

  • Authority to build and publish releases at the published release date under the auspices of the CNCF
  • Authority to accept or reject cherrypick merge requests to the release branch
  • Authority to accept or reject PRs to the kubernetes/kubernetes master branch during code slush period
  • Changing the release timeline as needed if keeping it would materially impact the stability or quality of the release these responsibilities will continue to be discharged by SIG release through the Release Team. This charter grants SIG Release the following additional responsibilities
  • Authority to revert code changes which imperil the ability to produce a release by the communicated date or otherwise negatively impact the quality of the release (e.g. insufficient testing, lack of documentation)
  • Authority to guard code changes behind a feature flag which do not meet criteria for release
  • Authority to close the submit queue to any changes which do not target the release as part of enforcing the code slush period which shall be the discharged by the Release Team.

Specific responsibilities

  • Support SIG PM by providing tooling and processes for the generation of release notes
  • Coordinate with SIG PM to communicate enhancement burndown progress during a release cycle
  • Manage repositories and tooling dedicated to releasing Kubernetes which at time of chartering these include:
    • kubernetes/release
    • deb/rpm packaging and hosting
    • Container image hosting
  • Set and enforce criteria for repository inclusion in a Kubernetes release
    • Governance
    • Stabilization
    • Test coverage
  • Set and enforce criteria for code inclusion in a Kubernetes release
    • Feature flags
    • Documentation
    • Test coverage
    • Dashboards
    • Status reports
  • Define template and format for communication of release status
    • Ongoing status of the release process
    • Announcement of alpha, beta, release candidate availability
    • Announcement of release availability
  • Deriving signal from the following sources
  • Identifying owning individuals and SIGs for blocking issues
  • Working with SIGs and individuals to drive resolution of open issues
  • Building summary of release criteria and status and publish to the community on a regular basis throughout the release cycle
  • Manage the contents of kubernetes/enhancements along with SIG PM
  • Define burndown process
    • use of GitHub labels to signal release blocking status
    • use of GitHub milestones to communicate release blocking issues
    • use of flake GitHub issue count or CI signal as a release blocking status
  • Coordinate the resolution of release blocking issues

Kubernetes Release Team roles

As documented in the Kubernetes Versioning doc, there are 3 types of Kubernetes releases:

  • Major (x.0.0)
  • Minor (x.x.0)
  • Patch (x.x.x)
Role Handbook
Release Team Lead Lead Handbook
Enhancements Enhancements Handbook
CI Signal CI Signal Handbook
Test Infra Test Infra Handbook
Bug Triage Bug Triage Handbook
Branch Manager Branch Manager Handbook
Docs Doc Handbook
Release Notes Release Notes Handbook
Communications Communications Handbook
Patch Release Management Team Patch Release Handbook

Release Team Shadow

Any Release Team member may select one or more mentees to shadow the release process in order to help fulfill future Release Team staffing requirements and continue to grow the Kubernetes community in general. Potential mentees should be prepared to devote a significant amount of time to shadowing their mentor during the release cycle. Successful Release Team Shadows should be prepared to assume a lead role in a subsequent release.

Individual Contributors

Release responsibilities of individual contributors to the Kubernetes project are captured below

During a patch release

If you have a patch that needs to be ported back to a previous release (meaning it is a critical bug/security fix), once it is merged to the Kubernetes master branch:

During a major/minor release

Propose and track enhancement

If you are developing an enhancement for Kubernetes, make sure that an issue is open in the enhancements repository. If you are targeting a particular release, make sure the issue is marked with the corresponding release milestone.

Ensure that all code for your enhancement is written, tested, reviewed, and merged before code freeze date for the target release.

During the code freeze period, fix any bugs discovered with your enhancement, and write enhancement documentation.

Write enhancement documentation
  1. Make sure your enhancement for the upcoming release is on the release tracking board (e.g. link for 1.6).
  2. Create a PR with documentation for your enhancement in the documents repo.
    • Your PR should target the release branch (e.g. release-1.6), not the master branch.
      • Any changes to the master branch become live on https://kubernetes.io/docs/ as soon as they are merged, and for releases we do not want documentation to go live until the release is cut.
  3. Add link to your docs PR in the release tracking board, and notify the docs lead for the release (e.g. Devin Donnelly for 1.6).
  4. The docs lead will review your PR and give you feedback.
  5. Once approved, the docs lead will merge your PR into the release branch.
  6. When the release is cut, the docs lead will push the docs release branch to master, making your docs live on https://kubernetes.io/docs/.

Other activities of the Release Team

During "Major" releases

To date no major release has been scheduled, however, SIG Release would be responsible for working closely with SIG PM and SIG Testing to coordinate this effort across SIGs. The precise work required to produce a major release (e.g. 2.0, 3.0) is undefined.

During "Security" releases

For all unplanned or embargoed releases

Release Team Selection

In addition to discharging the duties of their respective Release Team roles, the current Release Team is charged with selecting the team for the following release cycle.

Team selection should happen transparently.

In the 1.11 release cycle, we selected the Release Team Lead by quorum during a public Release Team meeting and additional roles were staffed via an issue in k/sig-release and a set of PRs, starting with this one.

Each Release Team role is responsible for staffing their respective role, with this order of fall-through in mind:

  • training and selecting a successor from the current pool of role shadows
  • training and selecting a successor from non-Release Team members
  • staffing the role themselves

Ultimately, if none of these can be satisfied, responsibility falls to the future Release Team Lead and SIG Release to staff the roles.

Release Team Lead Selection

The incoming Release Team Lead MUST have participated on the Release Team for 2 or more release cycles, acting in a lead (non-shadow) capacity for at least one of those cycles.

Release Team Leads should be staffed, with this order of fall-through in mind:

  • the current pool of Release Team Lead shadows
  • the current pool of Release Team members
  • former Release Team members

Bear in mind that these are suggestions based on precedent and a Release Team Lead may be nominated by any Release Team member, past or present.

The new Release Team Lead can be selected via lazy consensus of the current Release Team members.

Shadows

Every Release Team role should seek to accommodate a set of role shadows. This creates a new avenue for code and non-code contributors alike to contribute to the project. Additionally, it seeds future release cycles with new leaders.

While there isn't a strict restriction on the amount of shadows, we've found three shadows per role to be a reasonable upper bound.

If there are more contributors interested in shadowing once hitting that upper bound, we welcome them to sit in on Release Team meetings in preparation for shadowing in a future release cycle.

Considerations

Timing

Staff early! The Release Team should undertake the selection process at the beginning Code Freeze, with a deadline of three days following the current release.

Any staffing decisions that cannot be made within this timeframe should be escalated to SIG Release Chairs and discussed publicly.

Membership

Try to ensure potential Release Team candidates:

  • can commit to the amount of time required across the release cycle
  • are enthusiastic about being on the release team
  • are members of the relevant SIGs for their role, if applicable
  • have some prior experience with contributing to Kubernetes (such as shadowing a role for a prior release)

Most importantly, strive for diversity in:

  • gender identity
  • ethnicity
  • nationality
  • locality
  • company affiliation

Milestone Maintainers

Across release cycles, one of the best signals for issue triage is whether or not an issue or PR is actually targeted for the current milestone.

To maintain up-to-date status on milestone inclusion, we rely on a set of Milestone Maintainers (members of the kubernetes-milestone-maintainers GitHub team) to apply the appropriate labels to issues / PRs. This is facilitated by /milestone commands and bot automation.

Each release cycle, the current Release Team Lead must update membership to the aforementioned GitHub team.

Maintainers of the kubernetes-milestone-maintainers GitHub team are defined as follows:

  • SIG Release Chairs
  • Current Release Team Lead

Members of the kubernetes-milestone-maintainers GitHub team can include:

  • SIG leadership (SIG Chairs / Technical Leads) from all SIGs
  • SIG milestone maintainers from all SIGs (in addition to SIG leadership)
  • Special code reviewers, as selected by SIG Release

Maintainers of the GitHub team can, with justification, add or remove members at any time during release cycles.

Members are expected to actively triage issues and PRs to retain membership in kubernetes-milestone maintainers. Members not fulfilling the duties of this role should be removed.

Filing exceptions

The process for filing an enhancement exception can be found here.