Create SIG Release #596

calebamiles · 2017-05-03T19:41:03Z

Signed-off-by: caleb miles caleb.miles@coreos.com

calebamiles · 2017-05-03T19:41:17Z

grodrigues3 · 2017-05-03T20:32:59Z

sig-release/README.md

+# SIG Release
+
+### Table of Contents
+- [Purpose](#purpose)


nit: TOC order doesn't match doc order (purpose is after join us in doc)

spiffxp · 2017-05-03T21:01:02Z

sig-release/README.md

+- 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


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?

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.

spiffxp · 2017-05-03T21:02:47Z

sig-release/README.md

+- 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


What's a subarea?

spiffxp · 2017-05-03T21:11:43Z

sig-release/README.md

+- 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 


s/these/These

spiffxp · 2017-05-03T21:17:09Z

sig-release/README.md

+ - 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 


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

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.

spiffxp · 2017-05-03T21:19:46Z

sig-release/README.md

+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 


Dare I ask whether we ever consider the possibility of a Major release?

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.

spiffxp · 2017-05-03T21:22:13Z

sig-release/members.md

@@ -0,0 +1,8 @@
+## SIG Release Membership


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

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

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.

@calebamiles do we need to count the heads of members? I've been speaking about the people with the leadership role.

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

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

same here, this feels like it may turn into more administrivia than it's worth, but let's find out

grodrigues3 · 2017-05-03T21:25:36Z

sig-release/README.md

+
+## Broad responsibilities
+- Ensuring high quality Kubernetes releases
+ - Define and staff release roles to manage resolving and communicating the status of release blocking criteria


link to release roles doc

grodrigues3 · 2017-05-03T21:26:26Z

sig-release/README.md

+ - 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


last two phrases are redundant I think

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

grodrigues3 · 2017-05-03T21:29:53Z

sig-release/README.md

+ - Binary distributions
+ - Release notes
+- Continually improving release and development processes
+ - Define and build tools to facilitate release process (e.g. dashboards)


I'm all for this, but please work with contribX. I don't want to duplicate work where possible

Agree with @grodrigues3, let's not duplicate the responsibilities.

grodrigues3 · 2017-05-03T21:32:46Z

sig-release/README.md

+ - Test coverage
+ - Dashboards
+ - Status reports
+- Define template and format release communications


This has some overlap with the docs and pm team too. Does this include things like blog posts and announcements

was not thinking it included blog posts.

grodrigues3 · 2017-05-03T21:34:36Z

sig-release/README.md

+
+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 


e.g. undocumented features, untested or not sufficiently tested features,

grodrigues3 · 2017-05-03T21:36:40Z

sig-release/README.md

+
+### "Minor" Releases 
+For each minor release (e.g. 1.7, 1.8)
+- Shepherd each release to completion


What does this mean? I think this is the release-team's job not the sig-release

these are all under the "ongoing responsibilities of the Release Team" header

grodrigues3 · 2017-05-03T21:39:13Z

sig-release/README.md

+- 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


I think this is the release team as well

under the same heading

grodrigues3 · 2017-05-03T21:47:21Z

sig-release/README.md

+ (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


I think the release team does and should be responsible for these things.

grodrigues3 · 2017-05-03T21:54:47Z

@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:

Staff the release team and resolve discussions surrounding staff
Define policies to promote stable timely releases
Define/refine release roles as the project evolves
Provide guidance to current release team as needed
Grow and mentor the community so we have a capable, knowledgeable pool of contributors ready to take on release team roles

It should not actually manage a release and do things like:

Grant exceptions to features outside of the feature freeze
Enforce release policies (docs completion, release notes completion, testing, etc)
Create release branches

I think those kinds of things are the responsibility of the release team.

spiffxp · 2017-05-03T22:59:29Z

@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

spiffxp · 2017-05-03T23:05:02Z

sig-release/README.md

+
+## Join us!
+- [Google group](https://groups.google.com/forum/#!forum/kubernetes-sig-release)
+- [Slack channel](https://kubernetes.slack.com/messages/C56HWQ0TH/)


There is also #k8s-release as used by the release team, should that be decommissioned?

In order to not lose the history, should the old channel just be renamed and take over for the new channel?

rename sounds good

idvoretskyi · 2017-05-03T23:48:20Z

sig-release/README.md

+ - Binary distributions
+ - Release notes
+- Continually improving release and development processes
+ - Define and build tools to facilitate release process (e.g. dashboards)


Agree with @grodrigues3, let's not duplicate the responsibilities.

idvoretskyi · 2017-05-03T23:50:26Z

sig-release/README.md

+- 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


Feature freeze enforcement has to be performed by a release team, together with SIG-PM.

idvoretskyi · 2017-05-03T23:51:48Z

sig-release/members.md

@@ -0,0 +1,8 @@
+## SIG Release Membership


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

grodrigues3 · 2017-05-04T00:12:07Z

@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

pwittrock · 2017-05-09T19:07:46Z

@calebamiles Are we close to merging this?

luxas · 2017-05-09T19:21:20Z

Also related: kubernetes/enhancements#288

calebamiles · 2017-05-09T20:03:35Z

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.

grodrigues3 · 2017-05-09T23:58:22Z

last open comment looks resolved for now.

/lgtm

grodrigues3 · 2017-05-10T00:02:49Z

sig-release/README.md

+- 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!


nit: can you add a link to meeting notes. And possibly create a google doc based off one of the other sigs meeting notes

calebamiles · 2017-05-10T11:51:09Z

sig-release/README.md

+## 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)


https://docs.google.com/document/d/1vhsixdT58iJFfoGZbpmvI_xnK59XyAjtadu3h6hHPpY/edit?usp=sharing

As discussed on [kubernetes-dev](https://groups.google.com/forum/#!topic/kubernetes-dev/tOBsGSwOcJM) Signed-off-by: caleb miles <caleb.miles@coreos.com>

* Start 2021 Community Seat election process. * update steering members

calebamiles assigned calebamiles, grodrigues3 and pwittrock May 3, 2017

calebamiles requested review from spiffxp, idvoretskyi, marun, ethernetdan, grodrigues3, bgrant0607, pwittrock and matchstick May 3, 2017 19:41

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels May 3, 2017

calebamiles requested a review from philips May 3, 2017 19:41

david-mcmahon self-requested a review May 3, 2017 20:30

grodrigues3 reviewed May 3, 2017

View reviewed changes

spiffxp reviewed May 3, 2017

View reviewed changes

grodrigues3 reviewed May 3, 2017

View reviewed changes

spiffxp reviewed May 3, 2017

View reviewed changes

idvoretskyi reviewed May 3, 2017

View reviewed changes

spiffxp approved these changes May 9, 2017

View reviewed changes

calebamiles force-pushed the propose-sig-release branch from 099fa45 to 4eb4a54 Compare May 9, 2017 21:45

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 9, 2017

grodrigues3 reviewed May 10, 2017

View reviewed changes

calebamiles commented May 10, 2017

View reviewed changes

Create SIG Release

49d5df7

As discussed on [kubernetes-dev](https://groups.google.com/forum/#!topic/kubernetes-dev/tOBsGSwOcJM) Signed-off-by: caleb miles <caleb.miles@coreos.com>

calebamiles force-pushed the propose-sig-release branch from 4eb4a54 to 49d5df7 Compare May 10, 2017 11:55

calebamiles merged commit 2c18850 into kubernetes:master May 10, 2017

calebamiles deleted the propose-sig-release branch May 10, 2017 11:56

danehans pushed a commit to danehans/community that referenced this pull request Jul 18, 2023

Start 2021 Community Seat election process. (kubernetes#596)

f770baa

* Start 2021 Community Seat election process. * update steering members

Create SIG Release #596

Create SIG Release #596

Conversation

calebamiles commented May 3, 2017

calebamiles commented May 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

david-mcmahon May 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grodrigues3 commented May 3, 2017

spiffxp commented May 3, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

grodrigues3 commented May 4, 2017

pwittrock commented May 9, 2017

luxas commented May 9, 2017

calebamiles commented May 9, 2017

grodrigues3 commented May 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

david-mcmahon May 3, 2017 •

edited

Loading