-
Notifications
You must be signed in to change notification settings - Fork 396
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Stephen Augustus <foo@agst.us>
- Loading branch information
1 parent
4a2047d
commit e801bff
Showing
2 changed files
with
82 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,38 +1,19 @@ | ||
# SIG Release | ||
|
||
## Mission | ||
- Production of high quality Kubernetes releases on a reliable schedule | ||
- Ensure there is a [consistent group of community members][1.6-retro] in place to support the release process | ||
- Provide guidance and tooling to facilitate the production of automated releases | ||
- Serve as a tightly integrated partner with other SIGs to empower SIGs to integrate their repositories into the release process | ||
## Charter | ||
|
||
## Join us! | ||
- [Google group](https://groups.google.com/forum/#!forum/kubernetes-sig-release) | ||
- [Slack channel](https://kubernetes.slack.com/messages/C2C40FMNF/) | ||
- [Events and meetings calendar](https://calendar.google.com/calendar/embed?src=coreos.com_regcvcrgvq98lua2ikijg1g1uk%40group.calendar.google.com&ctz=America/Los_Angeles) | ||
- [Meeting agenda and notes](https://docs.google.com/document/d/1Fu6HxXQu8wl6TwloGUEOXVzZ1rwZ72IAhglnaAMCPqA/edit) ([read-only archive](https://docs.google.com/a/google.com/document/d/e/2PACX-1vRsGZTlmggTI5T4ysYGlaJiaW3vgnrc_dlv-B1nnt69gU2Xt6vzRpZDMm-7driIj14T1DraicGzkAHr/pub)) | ||
The [charter] defines the scope and governance of the Release Special Interest Group. | ||
|
||
## Responsibilities | ||
- Ensuring high quality Kubernetes releases | ||
- Define and staff release roles to manage the resolution of release blocking criteria | ||
- Define and drive development processes (e.g. merge queues, cherrypicks) and release processes | ||
(e.g. burndown meetings, cutting beta releases) with the intent of meeting the release schedule | ||
- Manage the creation of release specific artifacts including | ||
- Code branches | ||
- Binary distributions | ||
- Release notes | ||
- Continually improving release and development processes | ||
- Work closely with SIG Contributor Experience to define and build tools to facilitate release process (e.g. dashboards) | ||
- Work with downstream communities responsible for packaging Kubernetes releases | ||
- Work with other SIGs to agree upon the responsibilities of their SIG with respect to the release | ||
- Define and collect metrics related to the release in order to measure progress over each release | ||
- Collaboration with downstream communities which build artifacts from Kubernetes releases | ||
- Ensure the appropriate level of integration with publishing the OSS build artifacts | ||
## Join us! | ||
- [Slack](https://kubernetes.slack.com/messages/sig-release) | ||
- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-release) | ||
- [Open Issues / PRs](https://github.com/search?q=org%3Akubernetes+org%3Akubernetes-client+org%3Akubernetes-csi+org%3Akubernetes-incubator+org%3Akubernetes-retired+org%3Akubernetes-sigs+is%3Aopen+label%3Asig%2Frelease) | ||
- [Meeting agenda and notes](https://docs.google.com/document/d/1Fu6HxXQu8wl6TwloGUEOXVzZ1rwZ72IAhglnaAMCPqA/edit) | ||
|
||
## 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][rt-directory]. | ||
|
||
|
||
[1.6-retro]: https://docs.google.com/a/google.com/document/d/1JAUqKl-lYdYLQ7GUT_9LzqxwQv-PcOdyAxNRZKItajo/edit?usp=sharing | ||
[charter]: charter.md | ||
[rt-directory]: /release-team/README.md |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,74 @@ | ||
# SIG Release Charter | ||
|
||
This charter adheres to the conventions described in the [Kubernetes Charter README] and uses the Roles and Organization Management outlined in [sig-governance]. | ||
|
||
## Scope | ||
|
||
- Production of Kubernetes releases on a reliable schedule | ||
- Ensure there is a consistent group of community members in place to support the release process across time | ||
- Provide guidance and tooling to facilitate the production of automated releases | ||
- Serve as a tightly integrated partner with other SIGs to empower SIGs to integrate their repositories into the release process | ||
|
||
### In scope | ||
|
||
- Ensuring quality Kubernetes releases | ||
- Defining and staffing release roles to manage the resolution 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 schedule | ||
- Managing the creation of release specific artifacts, including: | ||
- Code branches | ||
- Binary artifacts | ||
- Release notes | ||
- Continually improving release and development processes | ||
- Working closely with SIG Contributor Experience to define and build tools to facilitate release process (e.g. dashboards) | ||
- Working closely with SIG Testing to determine and implement tests, automation, and labeling required for stable releases | ||
- Working with downstream communities responsible for packaging Kubernetes releases | ||
- Working with other SIGs to agree upon the responsibilities of their SIG with respect to the release | ||
- Defining and collecting metrics related to the release in order to measure progress over each release | ||
- Facilitating release retrospectives in conjunction with SIG PM | ||
- Collaborating with downstream communities which build artifacts from Kubernetes releases | ||
- Ensuring the appropriate level of integration with publishing the build artifacts | ||
|
||
### Out of scope | ||
|
||
#### Support | ||
|
||
SIG Release itself is not responsible for end user support or creation of patches for support streams. There are support forums for end users to ask questions and report bugs, subject matter experts in other SIGs triage and address issues and when necessary mark bug fixes for inclusion in a patch release. | ||
|
||
## Roles and Organization Management | ||
|
||
This SIG adheres to the Roles and Organization Management outlined in [sig-governance] and opts-in to updates and modifications to [sig-governance]. | ||
|
||
Specifically, the common guidelines (see: [sig-governance]) for continuity of membership within roles in the SIG are followed. | ||
|
||
### Deviations from [sig-governance] | ||
|
||
- SIG Release does not have top-level SIG Technical Leads; SIG Release Chairs can serve in both an operational and technical capacity | ||
- SIG Release subprojects have subproject chairs | ||
|
||
#### SIG Membership | ||
|
||
Additionally, SIG Release has a concept of membership. SIG members can be occasionally called on to assist with decision making, especially as it relates to gathering historical context around existing policies. | ||
|
||
While a strict definition of membership has yet to be established, we will initially seed a set of members from the list of all documented former Release Team members and subproject OWNERS. | ||
|
||
SIG Release Members should be the first group of community members considered when seeking to fill additional roles across SIG Release proper and SIG Release subprojects, except where explicitly defined in other policy. | ||
|
||
### Subproject Creation | ||
|
||
- Subprojects must be created by [KEP] proposal and accepted by [lazy-consensus] with fallback on majority vote of | ||
SIG Chairs. The result *SHOULD* be supported by the majority of SIG members. | ||
- KEP *MUST* establish subproject chairs | ||
- [sigs.yaml] *MUST* be updated to include subproject information and OWNERS files with subproject chairs | ||
- Where subprojects processes differ from the SIG governance, they must document how | ||
- e.g., if subprojects release separately - they must document how release and planning is performed | ||
|
||
|
||
[KEP]: https://git.k8s.io/community/keps/0000-kep-template.md | ||
[Kubernetes Charter README]: https://git.k8s.io/community/committee-steering/governance/README.md | ||
[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus | ||
[rt-directory]: /release-team/README.md | ||
[sig-governance]: https://git.k8s.io/community/committee-steering/governance/sig-governance.md | ||
[sig-members]: members. | ||
[sig-subprojects]: https://git.k8s.io/community/sig-release/README.md#subprojects | ||
[sigs.yaml]: https://git.k8s.io/community/sigs.yaml |