-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Create SIG Release #596
Create SIG Release #596
Conversation
cc: @philips, @sarahnovotny |
sig-release/README.md
Outdated
# SIG Release | ||
|
||
### Table of Contents | ||
- [Purpose](#purpose) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: TOC order doesn't match doc order (purpose is after join us in doc)
sig-release/README.md
Outdated
- Production of high quality Kubernetes releases on a reliable schedule | ||
- Ensure there is a [consistent group of community members](https://docs.google.com/document/d/1JAUqKl-lYdYLQ7GUT_9LzqxwQv-PcOdyAxNRZKItajo/edit) [1] 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 integration their repositories into the release process |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/integration/integrate
Is the idea to release N repos at once as part of a release? (eg: must kubernetes/kubernetes and kubernetes/kubernetes.github.io be "released" in lockstep?) I would spell out that list of repos explicitly in this doc if so
Or to provide a consistent release process that can be reused by other repos?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overall purpose/goal here is to ensure (early) collaboration and integration (tooling) with any release-critical repos outside of core kubernetes/kubernetes. I'm not sure we need to spell out that list here and now as there are no other repos that currently fall into this category? Maybe kubernetes/features for .0 releases.
Providing a more generalized release process is certainly part of this.
sig-release/README.md
Outdated
- Continually improving release and development processes | ||
- 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 subarea with respect to the release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's a subarea?
sig-release/README.md
Outdated
- 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/these/These
sig-release/README.md
Outdated
- Ensure 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kubernetes/features has historically been somewhat involved as a criteria for inclusion into a given release, it's unclear to me what the overlap would be with @kubernetes/kubernetes-pm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, reaching into kubernetes/features started late last year. Certainly worth including in this list. While the contents of the release notes files are the responsibility of many SIGs, the tooling to utilize/access it falls under SIG-release.
sig-release/README.md
Outdated
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dare I ask whether we ever consider the possibility of a Major release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe such a thing has ever even been discussed in the project, but it certainly would be a large discussion involving many SIGs with a strong focus on sig-testing and sig-release. I suspect we'll update SIG charters once we start planning to cross that bridge. It couldn't hurt to leave a placeholder here.
@@ -0,0 +1,8 @@ | |||
## SIG Release Membership |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend moving this into README.md as "Organizers" and use inclusion in the kubernetes-sig-release google group(s) as membership, rather than having to update this table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I second this. Everybody may join the SIG mailing list and be a "member". Let's use more common naming as "SIG leaders" (if the leadership is meant here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Google Group membership is insufficient for listing members for the purposes of communication. Personally communicating with me via email is the least effective way to reach me and my Google+ profile does not link my GitHub id which is practically a much more important identifier for the project. Moreover I would like to have all of our documentation listed in source control somewhere.
There is also a thread about having GitHub team membership information stored in source control for greater visibility for the community and I thought it makes sense to support that idea here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@calebamiles do we need to count the heads of members? I've been speaking about the people with the leadership role.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@idvoretskyi, I think we'll need to store the list of members (by GitHub id) somewhere in order to expose the membership of GitHub teams to non org members. Given that essentially any contribution to the project comes a PR sonewhere I think it's perfectly reasonable to expect people who want to declare their membership to file a PR to update the table themselves. People listed here should be more than passively invested in the goals of the SIG.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@calebamiles I'm ok with merging it as is - don't want this item to be a blocker.
But IMO, it's not a common practice for SIG's to have a similar list of people.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, this feels like it may turn into more administrivia than it's worth, but let's find out
sig-release/README.md
Outdated
|
||
## Broad responsibilities | ||
- Ensuring high quality Kubernetes releases | ||
- Define and staff release roles to manage resolving and communicating the status of release blocking criteria |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
link to release roles doc
sig-release/README.md
Outdated
- Define and staff release roles to manage resolving and communicating the status 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 timeline and delivering an | ||
on time release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
last two phrases are redundant I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, I think release/burndown process has been different for each release. I think this group is responsible for standardizing that (e.g. all issues in the milestone block the release, using blocking/non-blocking labels, test flake count, etc).
sig-release/README.md
Outdated
- Binary distributions | ||
- Release notes | ||
- Continually improving release and development processes | ||
- Define and build tools to facilitate release process (e.g. dashboards) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for this, but please work with contribX. I don't want to duplicate work where possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @grodrigues3, let's not duplicate the responsibilities.
sig-release/README.md
Outdated
- Test coverage | ||
- Dashboards | ||
- Status reports | ||
- Define template and format release communications |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has some overlap with the docs and pm team too. Does this include things like blog posts and announcements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was not thinking it included blog posts.
sig-release/README.md
Outdated
|
||
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. undocumented features, untested or not sufficiently tested features,
sig-release/README.md
Outdated
|
||
### "Minor" Releases | ||
For each minor release (e.g. 1.7, 1.8) | ||
- Shepherd each release to completion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean? I think this is the release-team's job not the sig-release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are all under the "ongoing responsibilities of the Release Team" header
sig-release/README.md
Outdated
- GitHub issues | ||
- Define and enforce development process as it relates to the release | ||
- Code slush time and Merge Queue access | ||
- Enforcing feature freeze + approving exceptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the release team as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
under the same heading
sig-release/README.md
Outdated
(e.g. burndown meetings, cutting beta releases) with the intent of meeting the release timeline and delivering an | ||
on time release | ||
- Manage the creation of release specific artifacts including | ||
- Code branches |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the release team does and should be responsible for these things.
@calebamiles thanks for getting the ball rolling on this. I think the most important part is defining the Purpose/Broad Responsibilities (which I think can be merged in the doc). Right now, many of the responsibilities seem to overlap with the release team. I think the release team is responsible for all the release specific jobs (stable release, on-time, burndowns, etc). Sig-release seems like it should:
It should not actually manage a release and do things like:
I think those kinds of things are the responsibility of the release team. |
@grodrigues3 FWIW my read was the release team is by definition a subset of SIG Release, and so it made sense to spell out their responsibilities here as well |
sig-release/README.md
Outdated
|
||
## Join us! | ||
- [Google group](https://groups.google.com/forum/#!forum/kubernetes-sig-release) | ||
- [Slack channel](https://kubernetes.slack.com/messages/C56HWQ0TH/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also #k8s-release as used by the release team, should that be decommissioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to not lose the history, should the old channel just be renamed and take over for the new channel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename sounds good
sig-release/README.md
Outdated
- Binary distributions | ||
- Release notes | ||
- Continually improving release and development processes | ||
- Define and build tools to facilitate release process (e.g. dashboards) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @grodrigues3, let's not duplicate the responsibilities.
sig-release/README.md
Outdated
- GitHub issues | ||
- Define and enforce development process as it relates to the release | ||
- Code slush time and Merge Queue access | ||
- Enforcing feature freeze + approving exceptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feature freeze enforcement has to be performed by a release team, together with SIG-PM.
@@ -0,0 +1,8 @@ | |||
## SIG Release Membership |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I second this. Everybody may join the SIG mailing list and be a "member". Let's use more common naming as "SIG leaders" (if the leadership is meant here).
@spiffxp in that case, I think we should merge these two docs. Doesn't make sense to specify the release team roles and responsibilities in two places, right? https://github.com/kubernetes/community/tree/master/contributors/devel/release |
@calebamiles Are we close to merging this? |
Also related: kubernetes/enhancements#288 |
I just got around to making the changes suggested by @spiffxp and @grodrigues3 (sorry at OpenStack Summit in Boston). If you could take a look, @pwittrock that would be great. To answer your question though I do think we're close to merging this. |
099fa45
to
4eb4a54
Compare
last open comment looks resolved for now. /lgtm |
- 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 | ||
|
||
## Join us! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can you add a link to meeting notes. And possibly create a google doc based off one of the other sigs meeting notes
## Join us! | ||
- [Google group](https://groups.google.com/forum/#!forum/kubernetes-sig-release) | ||
- [Slack channel](https://kubernetes.slack.com/messages/C56HWQ0TH/) | ||
- [Events and meetings calendar](https://calendar.google.com/calendar/embed?src=coreos.com_regcvcrgvq98lua2ikijg1g1uk%40group.calendar.google.com&ctz=America/Los_Angeles) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed on [kubernetes-dev](https://groups.google.com/forum/#!topic/kubernetes-dev/tOBsGSwOcJM) Signed-off-by: caleb miles <caleb.miles@coreos.com>
4eb4a54
to
49d5df7
Compare
* Start 2021 Community Seat election process. * update steering members
As discussed on kubernetes-dev
Signed-off-by: caleb miles caleb.miles@coreos.com