Skip to content

Instantly share code, notes, and snippets.

@calebamiles

calebamiles/sig-release-charter.md

Last active May 2, 2017 00:40
Show Gist options
  • Save calebamiles/e8088dba4d5b274f04e96e0d25a6c2d2 to your computer and use it in GitHub Desktop.
Save calebamiles/e8088dba4d5b274f04e96e0d25a6c2d2 to your computer and use it in GitHub Desktop.
Download ZIP
Propose charter for Kubernetes SIG Release
Raw
sig-release-charter.md

SIG Release

Purpose

  • Production of high quality Kubernetes releases on a reliable schedule
  • Ensure there is a consistent group of community members in place to support the release process [1]
  • Driving project wide changes necessary to both release bits continuously

Broad responsibilities

  • Ensuring high quality Kubernetes releases by:
    • defining and staffing release roles to manage resolving and communicating the status of release blocking criteria
    • defining and driving development processes (e.g. merge queues, cherrypicks) and release processes (e.g. burndown meetings, cutting beta releases) with the intent of meeting the release timeline and delivering an on time release
    • Managing the creation of release specific artifacts including
      • Code branches
      • Binary distributions
      • Release notes
  • Continually improving release and development processes by:
    • defining and building tools to facilitate release process (e.g. dashboards)
    • working with downstream communities responsible for packaging Kubernetes releases
    • working with other SIGs to agree upon the responsibilities of their subarea with respect to the release
    • defining and collecting metrics related to the release in order to measure progress over each release
  • Collaboration with downstream communities which build artifacts from Kubernetes releases by
    • ensuring the appropriate level of integration with publishing the OSS build artifacts

Specific responsibilities

  • 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
    • building summary of release criteria and status and publish to the community on a weekly basis.
    • dashboards
    • status reports
  • Define template and format release communications
  • Deriving signal from the following sources
  • Resolve release blocking issues
  • Identifying owning individuals and SIGs for blocking issues
  • Working with SIGs and individuals to drive resolution of open issues

Relation to the Release Manager and Team

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
  • 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.

Ongoing responsibilities of the release team

The release team will be responsible for the following items, as well as remaining active members of SIG-release for the duration of the release.

"Minor" Releases

For each minor release (e.g. 1.7, 1.8)

  • Shepherd each release to completion
  • Define and enforce release criteria
  • Test health
  • GitHub issues
  • Define and enforce development process as it relates to the release
  • Code slush time / Merge queue
  • Enforcing feature freeze + approving exceptions
  • Deciding which bug fixes to accept into a release post-feature freeze
  • Define and enforce release stabilization process
  • E2e flake fixes
  • Burndown meetings
  • Identify and staff release team roles
  • How above responsibilities are staffed
  • Publicize and solicit feedback on alpha/beta/release candidate artifacts from downstream consumers (e.g. kubeadm)
  • Collect and publish documentation for consumption of alpha/beta/release candidate artifacts

“Patch” releases

For each patch release (e.g. 1.6.x, 1.7.x, 1.8.x)

  • Support patches to publish “Minor” releases
  • Define release owner
  • Shepherd patch releases

"Security" releases

For all unplanned or embargoed releases

References

  1. https://docs.google.com/document/d/1JAUqKl-lYdYLQ7GUT_9LzqxwQv-PcOdyAxNRZKItajo/edit
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment