Skip to content

Latest commit

 

History

History
180 lines (137 loc) · 8.3 KB

release-managers.md

File metadata and controls

180 lines (137 loc) · 8.3 KB
Raw

Release Managers

"Release Managers" is an umbrella term that encompasses the set of Kubernetes contributors responsible for maintaining release branches, tagging releases, and building/packaging Kubernetes.

The responsibilities of each role are described below.

Contact

Mailing List Slack Visibility Usage Membership
release-managers@kubernetes.io #release-management (channel) / @release-managers (user group) Public Public discussion for Release Managers All Release Managers (including Associates, Build Admins, and SIG Chairs)
release-managers-private@kubernetes.io #release-private Private Private discussion for privileged Release Managers Release Managers, SIG Release leadership
security-release-team@kubernetes.io N/A Private Security release coordination with the Product Security Committee security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io

Handbooks

NOTE: The Patch Release Team and Branch Manager handbooks will be deduplicated at a later date.

Release Managers

Release Managers are responsible for:

  • Coordinating patch releases (x.y.z, where z > 0) of Kubernetes
  • Minor releases (x.y.z, where z = 0) of Kubernetes, working with the Release Team through each release cycle
  • Mentoring the Release Manager Associates group
  • Actively developing features and maintaining the code in k/release
  • Supporting Release Manager Associates and contributors through actively participating in the Buddy program
    • Check in monthly with Associates and delegate tasks, empower them to cut releases, and mentor
    • Being available to support Associates in onboarding new contributors e.g., answering questions and suggesting appropriate work for them to do

This team at times works in close conjunction with the Product Security Committee and therefore should abide by the guidelines set forth in the Security Release Process.

GitHub Access Controls: @kubernetes/release-managers

GitHub Mentions: @kubernetes/release-engineering

Becoming a Release Manager

To become a Release Manager, one must first serve as a Release Manager Associate. Associates graduate to Release Manager by actively working on releases over several cycles and:

  • demonstrating the willingness to lead
  • tag-teaming with Release Managers on patches, to eventually cut a release independently
    • because releases have a limiting function, we also consider substantial contributions to image promotion and other core Release Engineering tasks
  • questioning how Associates work, suggesting improvements, gathering feedback, and driving change
  • being reliable and responsive
  • leaning into advanced work that requires Release Manager-level access and privileges to complete

Release Manager Associates

Release Manager Associates are apprentices to the Release Managers, formerly referred to as Release Manager shadows. They are responsible for:

  • Patch release work, cherry pick review
  • Contributing to k/release: updating dependencies and getting used to the source codebase
  • Working on minor releases (x.y.z, where z = 0)
  • With help from a release manager, working with the Release Team during the release cycle
  • Seeking opportunities to help with prioritization and communication
    • Sending out pre-announcements and updates about patch releases
    • Updating the calendar
  • Through the Buddy program, onboarding new contributors and pairing up with them on tasks

GitHub Mentions: @kubernetes/release-engineering

Becoming a Release Manager Associate

Contributors can become Associates by demonstrating the following:

  • consistent participation, including 6-12 months of active release engineering-related work
  • experience fulfilling a technical lead role on the Release Team during a release cycle
    • this experience provides a solid baseline for understanding how SIG Release works overall—including our expectations regarding technical skills, communications/responsiveness, and reliability
  • working on k/release items that improve our interactions with Testgrid, cleaning up libraries, etc.
    • these efforts require interacting and pairing with Release Managers and Associates

Build Admins

Build Admins are (currently) Google employees with the requisite access to Google build systems/tooling to publish deb/rpm packages on behalf of the Kubernetes project. They are responsible for:

  • Building, signing, and publishing the deb/rpm packages
  • Being the interlock with Release Managers (and Associates) on the final steps of each minor (1.Y) and patch (1.Y.Z) release

GitHub team: @kubernetes/build-admins

SIG Release Leads

SIG Release Chairs and Technical Leads are responsible for:

  • The governance of SIG Release
  • Leading knowledge exchange sessions for Release Managers and Associates
  • Coaching on leadership and prioritization

They are mentioned explicitly here as they are owners of the various communications channels and permissions groups (GitHub teams, GCP access) for each role. As such, they are highly privileged community members and privy to some private communications, which can at times relate to Kubernetes security disclosures.

GitHub team: @kubernetes/sig-release-leads

Chairs

Technical Leads

Past Branch Managers, can be found in the releases directory within release-x.y/release_team.md. Example: 1.15 Release Team