Re: Long Term Support Working Group proposal

Skip to first unread message

Timothy Pepper

Nov 26, 2018, 10:50:54 PM11/26/18

FYI we are in fact working on formally setting up a WG.


Slack:                                     #wg-lts


Meetings:                            biweekly Tuesday 9am Pacific (alternating weeks with SIG Cluster Lifecycle; will be adding one additional time for better global participation)

YouTube Playlist:    


k/community PR #2911 against sigs list

includes a draft charter.


Feedback and participation is VERY WELCOME!



Tim Pepper

Orchestration & Containers Lead

VMware Open Source Technology Center


From: <> on behalf of Timothy Pepper <>
Date: Monday, October 15, 2018 at 12:09 PM
To: "" <>
Cc: Dhawal Yogesh Bhanushali <>
Subject: Long Term Support Working Group proposal


The recent 1.12 release renewed community commentary that the project drops support of old releases too quickly.  Any support discussion dovetails into the “What is Kubernetes? Kernel? Distribution?” discussion.  With cloud provider and other monolith splitting you get a wider Kubernetes software bill of materials, which makes more complex test, validation, documentation, upgrades.  There’s even a question of whether a shorter release cycle might be useful too or instead of long term support.  So many questions, but we don’t arrive at clear answers or actions without a more formal focus. 


So we propose a Long Term Support Working Group (WG LTS) to provide a cross SIG location for focused collection of stakeholder feedback.   [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 LTS is the foregone conclusion.]


What would this working group aim to achieve?

  • We hope for involvement from external users/operators, vendors, distributors, and hosting providers and also from our project internal SIGs, especially Cluster Lifecycle, Cloud Provider, Release, Architecture, but certainly this touches on all the SIGs. 
  • With feedback, we can attempt an informed assessment on the tradeoffs of requirements and costs.  Is LTS the answer or not?  
    • If it is, we imagine the WG would disband having drafted a KEP, gotten it approved by the project broadly, and returned it to SIG Release to operationalize. 
    • If it is not, we perhaps find other answers to propose or at least have a better assessment documenting the state of the project’s support relative to its users’ requirements. 



We expect a best-case time line of discussions this fall, especially leveraging the upcoming two KubeCons, leading then to drafting of proposals and decisions in 2019.


Please see here for more information:

Especially the latter section of “Background Details”.


Next Steps:


We expect a large number of vigorous objectors and supporters, and encourage folks to openly express their thoughts. We will catalog responses. And we all SHOULD keep an open mind here. The point of this proposed working group is specifically to capture feedback and assess whether there is a forward path for incremental improvement to the project’s support processes.


We’re looking here and now for lazy consensus that a working group is the correct Kubernetes project forum to explore this problem space further…which is hopefully in accordance with the current process for working group formation (just changed today).

If that is achieved we’ll look at setting up discussion forums/meetings/etc.




Tim Pepper, Dhawal Bhanushali, & SIG-Release

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply all
Reply to author
0 new messages