New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wg-lts: add #2911

Merged
merged 1 commit into from Feb 1, 2019

Conversation

@tpepper
Copy link
Contributor

tpepper commented Nov 7, 2018

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

This comment has been minimized.

Copy link
Contributor Author

tpepper commented Nov 7, 2018

@k8s-ci-robot k8s-ci-robot requested review from imkin and quinton-hoole Nov 7, 2018

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented Nov 7, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

tpepper commented Nov 7, 2018

@cblecker

This comment has been minimized.

Copy link
Member

cblecker commented Nov 7, 2018

/committee steering
cc: @kubernetes/steering-committee

@jeefy

This comment has been minimized.

Copy link
Member

jeefy commented Nov 7, 2018

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

And coming from a medical software background, +10000000

Show resolved Hide resolved sig-list.md Outdated
@imkin

This comment has been minimized.

Copy link

imkin commented Nov 7, 2018

/lgtm

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

* 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

This comment has been minimized.

@bgrant0607

bgrant0607 Nov 8, 2018

Member

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

This comment has been minimized.

@tpepper

tpepper Nov 8, 2018

Author Contributor

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.

This comment has been minimized.

@bgrant0607

bgrant0607 Nov 9, 2018

Member

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.

This comment has been minimized.

@andrewsykim

This comment has been minimized.

@tpepper

tpepper Nov 27, 2018

Author Contributor

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

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

This comment has been minimized.

@bgrant0607

bgrant0607 Nov 8, 2018

Member

And the Security team

This comment has been minimized.

@tpepper

tpepper Nov 8, 2018

Author Contributor

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?

This comment has been minimized.

@bgrant0607

bgrant0607 Nov 9, 2018

Member

Probably, yes

This comment has been minimized.

@tpepper

tpepper Nov 27, 2018

Author Contributor

Added PST.

Show resolved Hide resolved wg-lts/charter.md Outdated
"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

This comment has been minimized.

@bgrant0607

bgrant0607 Nov 8, 2018

Member

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.

This comment has been minimized.

@tpepper

tpepper Nov 8, 2018

Author Contributor

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

This comment has been minimized.

@bgrant0607

bgrant0607 Nov 9, 2018

Member

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.

This comment has been minimized.

@tpepper

tpepper Nov 27, 2018

Author Contributor

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

@tpepper tpepper force-pushed the tpepper:wg_lts branch from 428c292 to ccc5492 Nov 27, 2018

@k8s-ci-robot k8s-ci-robot removed the lgtm label Nov 27, 2018

@tpepper

This comment has been minimized.

Copy link
Contributor Author

tpepper commented Nov 27, 2018

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

@justaugustus

This comment has been minimized.

Copy link
Member

justaugustus commented Nov 27, 2018

/cc

@timothysc
Copy link
Member

timothysc left a comment

Minor nits, but non-blocking IMO
/lgtm

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

This comment has been minimized.

@timothysc

timothysc Jan 30, 2019

Member

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

This comment has been minimized.

@tpepper

tpepper Jan 31, 2019

Author Contributor

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

sigs.yaml Outdated
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 comment has been minimized.

@timothysc

timothysc Jan 30, 2019

Member

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

* SIG API Machinery
* SIG CLI
* SIG Node

This comment has been minimized.

@timothysc

timothysc Jan 30, 2019

Member

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

This comment has been minimized.

@bgrant0607

bgrant0607 Jan 31, 2019

Member

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.

This comment has been minimized.

@spiffxp

spiffxp Jan 31, 2019

Member

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.

This comment has been minimized.

@neolit123

neolit123 Feb 1, 2019

Member

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

@tpepper tpepper force-pushed the tpepper:wg_lts branch from b601711 to 8e1f356 Jan 31, 2019

@k8s-ci-robot k8s-ci-robot removed the lgtm label Jan 31, 2019

@dchen1107

This comment has been minimized.

Copy link
Member

dchen1107 commented Feb 1, 2019

/lgtm

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

wg-lts: add
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 tpepper force-pushed the tpepper:wg_lts branch from 8e1f356 to 35e16f9 Feb 1, 2019

@k8s-ci-robot k8s-ci-robot removed the lgtm label Feb 1, 2019

@lavalamp

This comment has been minimized.

Copy link
Member

lavalamp commented Feb 1, 2019

/lgtm
/approve

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

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented Feb 1, 2019

@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

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented Feb 1, 2019

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

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

@lavalamp

This comment has been minimized.

Copy link
Member

lavalamp commented Feb 1, 2019

I seem to not have powers here, though.

@cblecker

This comment has been minimized.

Copy link
Member

cblecker commented Feb 1, 2019

@lavalamp too many assignees. github limits to 10

/lgtm

@imkin

This comment has been minimized.

Copy link

imkin commented Feb 1, 2019

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

@dims

This comment has been minimized.

Copy link
Member

dims commented Feb 1, 2019

/hold cancel

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

3 checks passed

cla/linuxfoundation tpepper authorized
Details
pull-community-verify Job succeeded.
Details
tide In merge pool.
Details
@spiffxp

This comment has been minimized.

Copy link
Member

spiffxp commented Feb 2, 2019

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

This comment has been minimized.

Copy link
Contributor

smarterclayton commented Feb 2, 2019

/lgtm

2 similar comments
@derekwaynecarr

This comment has been minimized.

Copy link
Member

derekwaynecarr commented Feb 2, 2019

/lgtm

@jbeda

This comment has been minimized.

Copy link
Contributor

jbeda commented Feb 5, 2019

/lgtm

@spiffxp

This comment has been minimized.

Copy link
Member

spiffxp commented Feb 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment