wg-lts: add #2911

tpepper · 2018-11-07T01:10:58Z

As per October 2018 discussion in SIG Release, k-dev mailing list,
etc., here's our proposal for the working group around evaluating
our support stance and making proposals for improvements.

While not required for a working group, this commit proposes an
initial charter for the WG LTS as this one has a notable potential
to at best bikeshed and at worst get mired in contention. Documenting
scope, goals, deliverables seems like a reasonable way to aim for
a collaborative analysis of where we are and constructive suggestions
toward improvement.

Signed-off-by: Tim Pepper tpepper@vmware.com

tpepper · 2018-11-07T01:11:16Z

/cc @imkin @nickyoung @quinton-hoole

k8s-ci-robot · 2018-11-07T01:11:18Z

@tpepper: GitHub didn't allow me to request PR reviews from the following users: nickyoung.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @imkin @nickyoung @quinton-hoole

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

tpepper · 2018-11-07T01:13:39Z

/assign @jdumars @calebamiles

cblecker · 2018-11-07T01:19:04Z

/committee steering
cc: @kubernetes/steering-committee

jeefy · 2018-11-07T01:21:41Z

This may be a controversial issue but I, for one, welcome our long-term-supporting overlords.

And coming from a medical software background, +10000000

sig-list.md

imkin · 2018-11-07T18:16:58Z

/lgtm

I like detailed charters. Otherwise new people do not have enough context on the "vision/charter".
Thanks for the verbosity @tpepper

bgrant0607 · 2018-11-08T01:20:48Z

wg-lts/charter.md

+* SIG Cloud Provider
+* SIG Testing
+* SIG Architecture & Steering Committee
+* ...arguably all SIGs in as much as proposals may impact the way the community developers, ships and maintains its code


SIGs API Machinery, CLI, and Node would be affected, in particular, if supported version skew were to change.

I can easily add these, but also wonder: In the sense of this being a WG not a SIG and thus not owning code, and KEPs being the form of any possible eventual change proposals...how specific should we be in this document? As I start adding, I can imagine additional arguments for why basically every SIG is a stakeholder, and even a blocking stakeholder in some cases. But somehow I think we need to differentiate between inputs / stakeholder involvement and outputs / blocking stakeholders.

Per-KEP I can imagine the possibility of some being more targeted and shorter stakeholder list, and some that would truly be all SIGs are blocking stakeholders on approval. I'd like to pragmatically allow that, and here in the document be indicating the intent to be as maximally inclusive as possible, without having to list every SIG and keep the list up to date as the SIG list morphs over the coming year.

If any wordsmiths have a solid proposal on how to do that I'd love suggestions.

Many of the stakeholders listed are not blocking stakeholders.

If you plan to seriously investigate the issue of version skew, then the SIGs I mentioned need to be consulted. I think they're far more significant than, say, SIG cloud provider. You can omit them from the doc, but that wouldn't give me confidence in the outcome of the WG.

cc @jagosan

Added SIGs API Machinery, CLI, and Node.

Also revamped this stakeholders section based on feedback from folks in the first WG LTS meeting (https://youtu.be/i1sCgfLFU-I?list=PL69nYSiGNLP13_zDqYfUjfLZ2Lu9a3pv-).

bgrant0607 · 2018-11-08T01:21:52Z

wg-lts/charter.md

+* Kubernetes end users
+* Kubernetes cluster operators
+* Kubernetes vendors, distributions, and hosting providers
+* SIG Release


And the Security team

This reminds me. The "security team" is not super discoverable right now. There's the new wg-security-audit here in the community repo and semi-buried in the sig-release repo: https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst

Do we need a better linkage and discoverability on that in the community repo?

Probably, yes

wg-lts/charter.md

bgrant0607 · 2018-11-08T01:24:47Z

wg-lts/charter.md

+"WG LTS" is simply shorter than "WG To LTS Or Not To LTS" or "WG
+What Are We Releasing And Why And How Is It Best Integrated, Validate,
+And Supported", but should NOT be read in that shortness to imply
+establishing a traditional LTS scheme is the foregone conclusion of


What is the user benefit that you think might be realized via LTS? What do you mean by "traditional LTS"? While the latter might be an output of the working group, it would be useful to state the former here.

Without getting super verbose on it, would a change from "traditional LTS scheme" to "traditional LTS scheme (multi-year support lifecycle)" be sufficient clarification?

That's a little better, but some implications, such as upgradability or lack thereof are unclear. I think the presentation was more clear. You could link to it.

Added link, and more perhaps clarifying wording around "traditional LTS scheme".

bgrant0607 · 2018-11-08T07:36:01Z

Other important background:
https://groups.google.com/d/msg/kubernetes-dev/Fqya3zlt0QQ/AC9RGeW6AwAJ
https://docs.google.com/presentation/d/1-Z-mUNIs3mUi7AdP1KwoAVNviwKrCoo3lxMb5wzCWbk/edit#slide=id.g401c104a3c_0_0
https://docs.google.com/document/d/1PWhUhm_a27BoWCGKZ5Bg6bV-DW-N06gIQIbrpwoscck/edit#heading=h.46dch1el9d8c
#2720

Regarding "Upgrade path across more distant releases":
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#supported-releases-and-component-skew
https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api
https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#backward-compatibility-gotchas
https://github.com/kubernetes/client-go#compatibility-client-go---kubernetes-clusters

tpepper · 2018-11-27T03:24:56Z

I've pushed some edits belatedly in response to feedback. KubeCon China and the US Thanksgiving holiday got me behind on things.

justaugustus · 2018-11-27T23:42:31Z

/cc

lavalamp · 2019-01-29T18:43:44Z

sigs.yaml

+    mission_statement: >
+      Provide a cross SIG location for focused collection of
+      stakeholder feedback regarding the support stance of Kubernetes
+      project in order to inform proposals for support improvements.


This mission statement is too vague. I suggest: "Answer the question: Does Kubernetes need a LTS (long-term-support) concept? If yes, figure out what that looks like for Kubernetes and propose this to the rest of the project. If no, figure out how to help end users cope with this and propose that to the rest of the project. If a proposal is accepted, the working group's mission will change to implement it."

I like this wording's specificity.

+1 from me on that.

I'm ok with the mission, but the name LTS doesn't necessarily align with the mission.

Can you actually change the mission statement in the document? I would like to lgtm.

LTS as a name maybe assumes the answer a little bit, but I don't think grammar forces you to interpret it that way, and it's hard to think of a better one. "wg-should-we-lts" and "wg-lts-or-not" don't exactly roll off the tongue.

As long as the mission statement is clear I think the name isn't a showstopper.

After some out-of-band discussion I'm going to amend with what is hopefully better word choice for all:

Answer the question: Does Kubernetes need a longer support term? If yes, figure out what that looks like for Kubernetes and propose this to the rest of the project. If no, figure out how to help end users cope with this and propose that to the rest of the project. If a proposal is accepted, the working group's mission will change to implement it.

"will change to implement it" ... we probably should add that this would be by working with/in relevant sigs

The new wording SGTM. +1

lavalamp · 2019-01-29T18:48:30Z

wg-lts/charter.md

+  for the release engineering operations and automation, but does not
+  own code itself.
+* Code, test case, automation implementations:  this is a working
+  group, no code implementation is the responsibility of this Working


WGs don't own code, but that doesn't mean you can't write or fix it.

timothysc

Minor nits, but non-blocking IMO
/lgtm

timothysc · 2018-11-27T17:54:52Z

OWNERS_ALIASES

@@ -66,7 +66,7 @@ aliases:
    - brancz
  sig-multicluster-leads:
    - csbell
-    - quinton-hoole
+    - quinton-hoole-2


The deets on multi-cluster should be a separate PR imo.

Definitely at this point should've gone in on it's own a long time ago. I've moved that commit to #3184

timothysc · 2019-01-30T21:57:11Z

sigs.yaml

+    mission_statement: >
+      Provide a cross SIG location for focused collection of
+      stakeholder feedback regarding the support stance of Kubernetes
+      project in order to inform proposals for support improvements.


I'm ok with the mission, but the name LTS doesn't necessarily align with the mission.

timothysc · 2019-01-30T21:58:13Z

wg-lts/README.md

+* SIG API Machinery
+* SIG CLI
+* SIG Node
+


What SIG is not a stakeholder? You might want to omit this section.

These specific SIGs would be most impacted by changes to our version-skew policies or upgrade/downgrade procedures.

But at this point, they are all aware this is happening, and will be looped into any resulting KEPs as appropriate, so I agree it's less necessary to include.

We need a list of SIGs so know from a process perspective whose lgtms are needed to move this forward. "Everyone" is untenable. I would consider which sigs are most likely to be actively involved in these discussions.

could this be handled as SIG Release being a primary stakeholder and stamper, while a note is added that any SIG can be potential stakeholders if a problem demands them to be?

scenario:

a SIG finds a problem, they send a PR for an LTS branch.

PR is stamped by said SIG, but final stamp is by SIG release.

with SIG Release in the above context i see the obvious requirement for a formation of a group that handles the LTS patch management and security evaluation of backports (AKA LTS release team).

dchen1107 · 2019-02-01T17:42:49Z

/lgtm

+1 on forming WG-LTS to discuss the possibility of having K8s LTS, hence make a rational go or no-go decision.

As per October 2018 discussion in SIG Release, k-dev mailing list, etc., here's our proposal for the working group around evaluating our support stance and making proposals for improvements. While not required for a working group, this commit proposes an initial charter for the WG LTS as this one has a notable potential to at best bikeshed and at worst get mired in contention. Documenting scope, goals, deliverables seems like a reasonable way to aim for a collaborative analysis of where we are and constructive suggestions toward improvement. Signed-off-by: Tim Pepper <tpepper@vmware.com>

lavalamp · 2019-02-01T18:09:07Z

/lgtm
/approve

I think enough people are signed on to merge this. Further changes can be made in follow-ups.

k8s-ci-robot · 2019-02-01T18:09:08Z

@lavalamp: changing LGTM is restricted to assignees, and assigning you to the PR failed.

In response to this:

/lgtm
/approve

I think enough people are signed on to merge this. Further changes can be made in follow-ups.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot · 2019-02-01T18:09:19Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: imkin, lavalamp, soltysh, timothysc, tpepper

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [timothysc]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

lavalamp · 2019-02-01T18:09:59Z

I seem to not have powers here, though.

cblecker · 2019-02-01T18:15:58Z

@lavalamp too many assignees. github limits to 10

/lgtm

imkin · 2019-02-01T19:49:43Z

@cblecker maybe it is waiting for "/hold cancel"

dims · 2019-02-01T20:17:21Z

/hold cancel

spiffxp · 2019-02-02T14:19:20Z

SIG sign-off was step one. This also needed sign-off from a simple majority of steering committee. I don't think that will be a problem but will go ask for lgtm's just to cross t's and dot i's.

Thus far we have 4 (@spiffxp, @dims, @timothysc, @bgrant0607) out of 12. So we need 3 more

smarterclayton · 2019-02-02T15:08:50Z

/lgtm

derekwaynecarr · 2019-02-02T16:24:40Z

/lgtm

jbeda · 2019-02-05T00:18:10Z

/lgtm

spiffxp · 2019-02-05T05:10:17Z

That's our 3 more. Simple majority of steering has agreed this WG should move forward. Thanks all.

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Nov 7, 2018

k8s-ci-robot requested review from idvoretskyi and jdumars November 7, 2018 01:11

k8s-ci-robot requested review from imkin and a user November 7, 2018 01:11

k8s-ci-robot assigned calebamiles and jdumars Nov 7, 2018

k8s-ci-robot added the committee/steering Denotes an issue or PR intended to be handled by the steering committee. label Nov 7, 2018

tpepper mentioned this pull request Nov 7, 2018

Kubernetes LTS Brainstorming #2720

Closed

quinton-hoole reviewed Nov 7, 2018

View reviewed changes

sig-list.md Outdated Show resolved Hide resolved

k8s-ci-robot added the sig/multicluster Categorizes an issue or PR as relevant to SIG Multicluster. label Nov 7, 2018

k8s-ci-robot assigned imkin Nov 7, 2018

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 7, 2018

bgrant0607 reviewed Nov 8, 2018

View reviewed changes

wg-lts/charter.md Outdated Show resolved Hide resolved

bgrant0607 reviewed Nov 8, 2018

View reviewed changes

bgrant0607 added the sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. label Nov 8, 2018

tpepper force-pushed the wg_lts branch from 428c292 to ccc5492 Compare November 27, 2018 03:07

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 27, 2018

lavalamp reviewed Jan 29, 2019

View reviewed changes

k8s-ci-robot assigned timothysc Jan 30, 2019

timothysc approved these changes Jan 30, 2019

View reviewed changes

k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jan 30, 2019

tpepper force-pushed the wg_lts branch from b601711 to 8e1f356 Compare January 31, 2019 20:18

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 31, 2019

k8s-ci-robot assigned dchen1107 Feb 1, 2019

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 1, 2019

tpepper force-pushed the wg_lts branch from 8e1f356 to 35e16f9 Compare February 1, 2019 17:54

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 1, 2019

cblecker unassigned calebamiles Feb 1, 2019

k8s-ci-robot assigned cblecker Feb 1, 2019

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 1, 2019

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 1, 2019

k8s-ci-robot merged commit 87db6fe into kubernetes:master Feb 1, 2019

wg-lts: add #2911

wg-lts: add #2911

Conversation

tpepper commented Nov 7, 2018

tpepper commented Nov 7, 2018

k8s-ci-robot commented Nov 7, 2018

tpepper commented Nov 7, 2018

cblecker commented Nov 7, 2018

jeefy commented Nov 7, 2018

imkin commented Nov 7, 2018

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

bgrant0607 commented Nov 8, 2018

tpepper commented Nov 27, 2018

justaugustus commented Nov 27, 2018

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

timothysc left a 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

dchen1107 commented Feb 1, 2019

lavalamp commented Feb 1, 2019

k8s-ci-robot commented Feb 1, 2019

k8s-ci-robot commented Feb 1, 2019

lavalamp commented Feb 1, 2019

cblecker commented Feb 1, 2019

imkin commented Feb 1, 2019

dims commented Feb 1, 2019

spiffxp commented Feb 2, 2019

smarterclayton commented Feb 2, 2019

derekwaynecarr commented Feb 2, 2019

jbeda commented Feb 5, 2019

spiffxp commented Feb 5, 2019