4 -> 3 releases per year?
245 views
Skip to first unread message
Tim St. Clair
Jan 2, 2018, 5:37:18 PM1/2/18
to kubernetes-dev
Folks -
I've bantered about this in a number of SIGs, but I want to float the
idea of releasing 3 vs. 4 times a year more broadly.
This has several motivations:
1. Our overhead per-release cycle is too high, and it has not gone
down over time.
2. The holiday quarter has always been weirdly compressed and forces
more punting than progress.
3. For most operators 4-releases a year is too much churn.
4. Our core-velocity should be slowing down over time.
...
Thoughts?
--
Cheers,
Timothy St. Clair
“Do all the good you can. By all the means you can. In all the ways
you can. In all the places you can. At all the times you can. To all
the people you can. As long as ever you can.”
I've bantered about this in a number of SIGs, but I want to float the
idea of releasing 3 vs. 4 times a year more broadly.
This has several motivations:
1. Our overhead per-release cycle is too high, and it has not gone
down over time.
2. The holiday quarter has always been weirdly compressed and forces
more punting than progress.
3. For most operators 4-releases a year is too much churn.
4. Our core-velocity should be slowing down over time.
...
Thoughts?
--
Cheers,
Timothy St. Clair
“Do all the good you can. By all the means you can. In all the ways
you can. In all the places you can. At all the times you can. To all
the people you can. As long as ever you can.”
Tim Hockin
Jan 2, 2018, 5:40:10 PM1/2/18
to Tim St. Clair, kubernetes-dev
I need to make a more formal proposal to go along with my kubecon
talk, but I think even 3 per year may be too much for "the whole
thing" to be released. That said, I support this proposal as "pretty
obviously better", to my eyes.
> --
> 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 kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
talk, but I think even 3 per year may be too much for "the whole
thing" to be released. That said, I support this proposal as "pretty
obviously better", to my eyes.
> 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 kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
Daniel Smith
Jan 2, 2018, 5:48:50 PM1/2/18
to Tim Hockin, Tim St. Clair, kubernetes-dev
I think we need two tracks.
1. LTS, once or twice per year.
- For people who don't like to upgrade very often.
- People on this track don't upgrade, they start up a new cluster and roll their workloads over.
- We backport security fixes for (e.g.) a year or two.
2. A biweekly or monthly stable.
- For people who want the latest features.
- Rollforward/rollback by one release would be supported and tested.
Both of the above are really deliverables of Kubernetes distributions, not "core", whatever that might be. It is weird because our main repo is a confusing mix of core components and distribution packaging. I think it is not easy to get here from where we are right now, but I'd support any step in the right direction.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
David Oppenheimer
Jan 2, 2018, 5:50:06 PM1/2/18
to Tim Hockin, Tim St. Clair, kubernetes-dev
Does this mean it would take a minimum of one year after something is released in alpha, for it to go to GA?
On Tue, Jan 2, 2018 at 2:39 PM, 'Tim Hockin' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
Clayton Coleman
Jan 2, 2018, 5:51:17 PM1/2/18
to David Oppenheimer, Tim Hockin, Tim St. Clair, kubernetes-dev
I think the bigger issue would be avoiding beta features in LTS style releases. Someone using an LTS version shouldn’t be using alpha or beta features in general.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
Tim St. Clair
Jan 2, 2018, 5:57:20 PM1/2/18
to Clayton Coleman, David Oppenheimer, Tim Hockin, kubernetes-dev
Before this thread spirals too much, what sig should own this, sig-release?
I'd think it should be a sub-project or working group to help refine
this process.
Ideally, I was hoping for a minimal short-term change, then evolve a
long-term process.
I'd think it should be a sub-project or working group to help refine
this process.
Ideally, I was hoping for a minimal short-term change, then evolve a
long-term process.
>> > an email to kubernetes-de...@googlegroups.com.
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> > To view this discussion on the web visit
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 kubernetes-de...@googlegroups.com.
>> To post to this group, send email to kuberne...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>> To post to this group, send email to kuberne...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
Tim Hockin
Jan 2, 2018, 6:02:16 PM1/2/18
to Clayton Coleman, David Oppenheimer, Tim St. Clair, kubernetes-dev
This is basically the thesis of my kubecon talk.
I like the idea that LTS is not upgradable. I am not sure it works,
but I like it.
I don't think beta should be verboten in LTS, but I could be
convinced. Certainly people need to understand the implications.
We have to re-decide what it means to be beta in this world, and what
the lifecycle of an effort will become.
We positioned our kubecon talk as "kernel vs distro" and that the
distro should release ~biannually. I had considered LTS be distinct
even from that. More like a regular "distro release" every 6 months,
and every 3rd or 4th release is LTS. The "kernel" would release more
frequently, and people could choose to get on a more frequent train.
What we really have to decide is how many of these usage modes we
really can afford to support as a community of cooperating/competing
entities. How many of these modes need "official" support? Do we
really need "official" LTS support or can that be handled
commercially? This is a very big topic..
I like the idea that LTS is not upgradable. I am not sure it works,
but I like it.
I don't think beta should be verboten in LTS, but I could be
convinced. Certainly people need to understand the implications.
We have to re-decide what it means to be beta in this world, and what
the lifecycle of an effort will become.
We positioned our kubecon talk as "kernel vs distro" and that the
distro should release ~biannually. I had considered LTS be distinct
even from that. More like a regular "distro release" every 6 months,
and every 3rd or 4th release is LTS. The "kernel" would release more
frequently, and people could choose to get on a more frequent train.
What we really have to decide is how many of these usage modes we
really can afford to support as a community of cooperating/competing
entities. How many of these modes need "official" support? Do we
really need "official" LTS support or can that be handled
commercially? This is a very big topic..
>> > an email to kubernetes-de...@googlegroups.com.
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> > To view this discussion on the web visit
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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
Clayton Coleman
Jan 2, 2018, 6:07:53 PM1/2/18
to Tim St. Clair, David Oppenheimer, Tim Hockin, kubernetes-dev
This pretty clearly seems like under sig-release aegis, with
significant feedback from a diverse set of contributors in general.
significant feedback from a diverse set of contributors in general.
Dan Kohn
Jan 2, 2018, 6:22:33 PM1/2/18
to Tim Hockin, Clayton Coleman, David Oppenheimer, Tim St. Clair, kubernetes-dev
Here's the PDF and YouTube for Tim's talk, in case you missed it:
--
Dan Kohn <d...@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
On Tue, Jan 2, 2018 at 6:01 PM, 'Tim Hockin' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:
This is basically the thesis of my kubecon talk.
I like the idea that LTS is not upgradable. I am not sure it works,
but I like it.
I don't think beta should be verboten in LTS, but I could be
convinced. Certainly people need to understand the implications.
We have to re-decide what it means to be beta in this world, and what
the lifecycle of an effort will become.
We positioned our kubecon talk as "kernel vs distro" and that the
distro should release ~biannually. I had considered LTS be distinct
even from that. More like a regular "distro release" every 6 months,
and every 3rd or 4th release is LTS. The "kernel" would release more
frequently, and people could choose to get on a more frequent train.
What we really have to decide is how many of these usage modes we
really can afford to support as a community of cooperating/competing
entities. How many of these modes need "official" support? Do we
really need "official" LTS support or can that be handled
commercially? This is a very big topic..
On Tue, Jan 2, 2018 at 2:51 PM, Clayton Coleman <ccol...@redhat.com> wrote:
> I think the bigger issue would be avoiding beta features in LTS style
> releases. Someone using an LTS version shouldn’t be using alpha or beta
> features in general.
>
> On Jan 2, 2018, at 5:50 PM, 'David Oppenheimer' via Kubernetes
>> > an email to kubernetes-dev+unsubscribe@googlegroups.com.
>> > To post to this group, send email to kubernetes-dev@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 kubernetes-dev+unsubscribe@googlegroups.com.
>> To post to this group, send email to kubernetes-dev@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_Rewbsx3BBLtKs2GzwGs0Q%3DmpW5W44O0K8T8dVvW%3DsxPuMmQ%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
Tim Hockin
Jan 2, 2018, 6:55:44 PM1/2/18
to Dan Kohn, Clayton Coleman, David Oppenheimer, Tim St. Clair, kubernetes-dev
NB that this is more of a problem statement than proposal. There are
very severe risks down all paths including the one we're currently
standing on.
>> > developer/contributor discussion <kuberne...@googlegroups.com>
>> >> > an email to kubernetes-de...@googlegroups.com.
>> >> > To post to this group, send email to kuberne...@googlegroups.com.
>> >> To post to this group, send email to kuberne...@googlegroups.com.
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> To post to this group, send email to kuberne...@googlegroups.com.
very severe risks down all paths including the one we're currently
standing on.
>> > wrote:
>> >
>> > Does this mean it would take a minimum of one year after something is
>> > released in alpha, for it to go to GA?
>> >
>> >
>> > On Tue, Jan 2, 2018 at 2:39 PM, 'Tim Hockin' via Kubernetes
>> > developer/contributor discussion <kuberne...@googlegroups.com>
>> >
>> > Does this mean it would take a minimum of one year after something is
>> > released in alpha, for it to go to GA?
>> >
>> >
>> > On Tue, Jan 2, 2018 at 2:39 PM, 'Tim Hockin' via Kubernetes
>> >> > To post to this group, send email to kuberne...@googlegroups.com.
>> >> > To view this discussion on the web visit
>> >> >
>> >> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> 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 kubernetes-de...@googlegroups.com.
>> >> >
>> >> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> 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
>> >> To post to this group, send email to kuberne...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > 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 kubernetes-de...@googlegroups.com.
>> >>
>> >> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > 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
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 kubernetes-de...@googlegroups.com.
>> >
>> > https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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
>> To post to this group, send email to kuberne...@googlegroups.com.
Michael Taufen
Jan 3, 2018, 8:28:18 PM1/3/18
to Tim Hockin, Dan Kohn, Clayton Coleman, David Oppenheimer, Tim St. Clair, kubernetes-dev
Coming back around to Tim St. Clair's initial suggestion:
There are a lot of interesting changes that can be done to improve our release model,
but they all seem like they require extensive discussion and work to implement
(e.g. it may be a long time before these "advanced" solutions mitigate our existing problems).
Cutting down to 3 releases per year seems like a relatively simple way to mitigate some of the
pressures we're feeling in the meantime, and maybe free up some resources to focus on what comes next.
Perhaps we should consider this as a first step?
>> > developer/contributor discussion <kubernetes-dev@googlegroups.com>
>> > wrote:
>> >
>> > Does this mean it would take a minimum of one year after something is
>> > released in alpha, for it to go to GA?
>> >
>> >
>> > On Tue, Jan 2, 2018 at 2:39 PM, 'Tim Hockin' via Kubernetes
>> > developer/contributor discussion <kubernetes-dev@googlegroups.com>
>> >> > an email to kubernetes-dev+unsubscribe@googlegroups.com.
>> >> > To post to this group, send email to kubernetes-dev@googlegroups.com.
>> >> > To view this discussion on the web visit
>> >> >
>> >> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> 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 kubernetes-dev+unsubscribe@googlegroups.com.
>> >> To post to this group, send email to kubernetes-dev@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > 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 kubernetes-dev+unsubscribe@googlegroups.com.
>> > To post to this group, send email to kubernetes-dev@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 kubernetes-dev+unsubscribe@googlegroups.com.
>> To post to this group, send email to kubernetes-dev@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAO_Rewbsx3BBLtKs2GzwGs0Q%3DmpW5W44O0K8T8dVvW%3DsxPuMmQ%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewZ2iv6H8srm4musbERK5SHD92rz1XCBiZDEamSVjts7Rw%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Michael Taufen
Google SWE
Christian Hüning
Jan 4, 2018, 1:04:03 AM1/4/18
to Kubernetes developer/contributor discussion
Great discussion, was wondering about the same in the recent past!
I think a slight slow-down in release frequency would take away some of the pressure, especially when you want to stay upstream'ish but simply can't afford to update to potentially breaking changes every at least every 3 months. On the other hand in our case we very much embraced the new features coming with each update. So taking that away would also be problematic.
Asking around on Slack etc., I heard different stories ranging from riding on the bleeding edge wave, doing a blue/green switch kinda thing between prod and staging clusters all the way to still running 1.5.x cause it works.
So I wondered, is there data about how many people running K8s in production or production-like systems actually keep up with upstream?
Best,
Christian
I think a slight slow-down in release frequency would take away some of the pressure, especially when you want to stay upstream'ish but simply can't afford to update to potentially breaking changes every at least every 3 months. On the other hand in our case we very much embraced the new features coming with each update. So taking that away would also be problematic.
Asking around on Slack etc., I heard different stories ranging from riding on the bleeding edge wave, doing a blue/green switch kinda thing between prod and staging clusters all the way to still running 1.5.x cause it works.
So I wondered, is there data about how many people running K8s in production or production-like systems actually keep up with upstream?
Best,
Christian
>> > developer/contributor discussion <kuberne...@googlegroups.com>
>> > wrote:
>> >
>> > Does this mean it would take a minimum of one year after something is
>> > released in alpha, for it to go to GA?
>> >
>> >
>> > On Tue, Jan 2, 2018 at 2:39 PM, 'Tim Hockin' via Kubernetes
>> > developer/contributor discussion <kuberne...@googlegroups.com>
>> >> > an email to kubernetes-de...@googlegroups.com.
>> >> > To post to this group, send email to kuberne...@googlegroups.com.
>> >> > To view this discussion on the web visit
>> >> >
>> >> > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9h10DCkXPmTwtVZQpgKXwK9h6PQNXHrp10ZHLW01RVRQ%40mail.gmail.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> 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 kubernetes-de...@googlegroups.com.
>> >> To post to this group, send email to kuberne...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewY86uNnAjLdSHeHdnebALeUzbVdk7jtOh1yt0fn3vZWNA%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > 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 kubernetes-de...@googlegroups.com.
>> > To post to this group, send email to kuberne...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcn5ES78jziGTBdUejgrCn8CH4Z-Q8qT1PoytmbpzyG0w%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 kubernetes-de...@googlegroups.com.
>> To post to this group, send email to kuberne...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAO_Rewbsx3BBLtKs2GzwGs0Q%3DmpW5W44O0K8T8dVvW%3DsxPuMmQ%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
--
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 kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewZ2iv6H8srm4musbERK5SHD92rz1XCBiZDEamSVjts7Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jaice Singer DuMars
Jan 4, 2018, 10:07:41 AM1/4/18
to Kubernetes developer/contributor discussion
Hi all,
No matter how long the release cycle is, all of the required release activities must go on at the same pace. Extending the cadence by a month just means an increased volume of documentation, release notes, tests, and so forth that inevitably get pushed to the last minute. While it may be a pessimistic view, I don't think we can extrapolate more coding time to earlier/more reliable delivery of release-related deliverables. If anything, it will make the release jobs like documentation much harder due to large volumes hitting all at once. Certainly we would need to revamp the release notes process, as Jennifer Rondeau can spell out in great detail. SIG Docs would also need to weigh in on this as stakeholders.
Another effect of longer releases is an increase of duty time for patch managers. This role can only be handled by a Google employee which creates an unfair burden there in terms of engineering time. The term of a patch manager would increase by 3 full months to a year in length. That is an excessive hardship in my opinion. At a minimum we would need to have two people dedicated to the task, as one person is stretched thin already. Other release roles will be hard to fill too, as 4 months is a lot of time to dedicate to a "second priority" unless it's somehow a compensated role.
We would also need to look at:
- How does a slower release cadence affect architectural initiatives? Does it make them take longer, or is there a way to use release gaps to do the work?
- Will longer releases potentially make stabilizing the release branch harder since it encompasses so much more change?
- Making the feedback loop longer between feature creation and delivery is a known anti-pattern, why are we not focused on faster or continuous releases instead?
I will second the desire for SIG-Release to lead the decision-making process, but not necessarily make it. At a minimum, the SIG leads (Caleb Miles and Phil Wittrock) should weigh in here, as well as Anthony, Dawn or other former release team members. This is a decision that affects the CNCF, contributors, consumers, and SIGs. I don't believe we currently have a consensus mechanism in place for making a decision of this scale. While it is tempting to toss this up to the steering committee, I don't believe that is the right answer either. This is not an internal arbitration issue, since it is under the auspices of a SIG already. We can discuss it at community meetings, on the mailing lists, in Slack, and in person, but I am concerned that it still doesn't provide a way of getting consensus.
I am sure we can find a way forward, but we need to be very cautious here.
All my best,
Jaice
Dan Kohn
Jan 4, 2018, 2:04:32 PM1/4/18
to Jaice Singer DuMars, Kubernetes developer/contributor discussion
Sorry for kibozing[0] CNCF, but I'll just mention that I don't think CNCF needs to weigh in on this decision. We're happy to support and market new releases at whatever rate the Kubernetes community decides to make them.
We did specifically consider the possibility of longer or shorter release schedules when designing the terms of the Certified Kubernetes program, and (hopefully) took that into account. The rule is that old certifications stay valid as long as you do at least one new certification each year[1], so it is not dependent on whether there are 3 or 4 releases in a year. We're also funding the update of the Certified Kubernetes Administrator exam [2] for each new version of Kubernetes (1.9 is a week or two away), but changing the release cycle would not be a big impact.
--
Dan Kohn <d...@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/2bdc0478-3465-407f-b591-c9661dac7939%40googlegroups.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
Jago Macleod
Jan 4, 2018, 7:21:44 PM1/4/18
to Dan Kohn, Jaice Singer DuMars, Kubernetes developer/contributor discussion
Hi Gang,
Great conversation so far. I wanted to bring the discussion back to points made previously in the thread and propose a different incremental improvement. I'm firmly in the camp that, though tempting, slowing down the release cadence--on its own--will just exacerbate the situation. Daniel mentioned a combo slower (LTS) and faster (latest/similar) and it occurs to me that we can improve the faster without changing the quarterly releases. That is, making a fully functional build every 2-4 weeks would likely reduce the challenges in the end-of-release scramble. Feature branches are helpful here but not required.
The other theme in this is the end-user upgrade cadence. I understand the motivation behind the reluctance to upgrade, but challenge the wisdom in encouraging / supporting this long term. Even if there is an LTS version, there will almost certainly be critical patches that require potentially disruptive upgrades. Reasonably frequent upgrades and client/server version skew, though difficult, should be assumed rather than suppressed. That said, it seems reasonable to have an O(annual) release that has only critical bug fixes and security patches, and for which upgrades/downgrades to and from the previous LTS-ish release are thoroughly tested.
To summarize, I suggest prioritization of the 'latest' / faster releases first, and only then move on to slowing down the existing release train, with a target of ~6months to a year between required major upgrades. From previous experience and for many of the reasons raised by Jaice and others, slowing down alone just makes matters worse.
Looking forward to continuing the discussion and happy 2018!
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/2bdc0478-3465-407f-b591-c9661dac7939%40googlegroups.com.
--
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 kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAHv71zLdBejS3eA4YVA14WsmVXj-4HFG%3DUeA7PJzPc9gJ9Nfvg%40mail.gmail.com.
Tim Hockin
Jan 8, 2018, 2:12:26 PM1/8/18
to Jago Macleod, Dan Kohn, Jaice Singer DuMars, Kubernetes developer/contributor discussion
I wonder if we have a shared comprehension of the problems we want to
solve. Many great perspectives here, so far, approaching from
different angles.
I don't mean this to be a comprehensive list, but some of the things
that I think may be at odds with each other:
* Desire to give customers a better experience (manifested as "slower"
by some and "more automatic and reliable" by others)
* Desire to offer LTS "bugfix only" releases
* Desire to make releases less chaotic and "last-second"
* Desire to relieve the pressure for developers to "catch the train"
* Desire to make alpha->beta->GA cycles easier (including deprecation & removal)
* Desire to factor the repos and efforts in a way that aligns with above
* Desire to make better / more stable releases
* Desire to accelerate (or not slow down) larger efforts
On Thu, Jan 4, 2018 at 4:21 PM, 'Jago Macleod' via Kubernetes
solve. Many great perspectives here, so far, approaching from
different angles.
I don't mean this to be a comprehensive list, but some of the things
that I think may be at odds with each other:
* Desire to give customers a better experience (manifested as "slower"
by some and "more automatic and reliable" by others)
* Desire to offer LTS "bugfix only" releases
* Desire to make releases less chaotic and "last-second"
* Desire to relieve the pressure for developers to "catch the train"
* Desire to make alpha->beta->GA cycles easier (including deprecation & removal)
* Desire to factor the repos and efforts in a way that aligns with above
* Desire to make better / more stable releases
* Desire to accelerate (or not slow down) larger efforts
On Thu, Jan 4, 2018 at 4:21 PM, 'Jago Macleod' via Kubernetes
>>> https://groups.google.com/d/msgid/kubernetes-dev/2bdc0478-3465-407f-b591-c9661dac7939%40googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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 kubernetes-de...@googlegroups.com.
>> To post to this group, send email to kuberne...@googlegroups.com.
>> To view this discussion on the web visit
>> To post to this group, send email to kuberne...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAHv71zLdBejS3eA4YVA14WsmVXj-4HFG%3DUeA7PJzPc9gJ9Nfvg%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAHf_GkDb-sMc61_XcMzdvQ1RSB-f88gg5OE5u9fRvc0bXWM0XA%40mail.gmail.com.
> 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 kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit
Brian Grant
Jan 8, 2018, 5:45:02 PM1/8/18
to Tim Hockin, Jago Macleod, Dan Kohn, Jaice Singer DuMars, Kubernetes developer/contributor discussion
FWIW, 1.1 and 1.2 were actually ~4-month releases. 1.3 was the start of the 3-month release cycle.
I share the concerns raised by Jaice and Jago.
Feature-branch discussion:
On Mon, Jan 8, 2018 at 11:12 AM, 'Tim Hockin' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:
I wonder if we have a shared comprehension of the problems we want to
solve. Many great perspectives here, so far, approaching from
different angles.
I don't mean this to be a comprehensive list, but some of the things
that I think may be at odds with each other:
* Desire to give customers a better experience (manifested as "slower"
by some and "more automatic and reliable" by others)
* Desire to offer LTS "bugfix only" releases
* Desire to make releases less chaotic and "last-second"
* Desire to relieve the pressure for developers to "catch the train"
* Desire to make alpha->beta->GA cycles easier (including deprecation & removal)
* Desire to factor the repos and efforts in a way that aligns with above
* Desire to make better / more stable releases
* Desire to accelerate (or not slow down) larger efforts
On Thu, Jan 4, 2018 at 4:21 PM, 'Jago Macleod' via Kubernetes
developer/contributor discussion <kubernetes-dev@googlegroups.com>
wrote:
>>> email to kubernetes-dev+unsubscribe@googlegroups.com.
>>> To post to this group, send email to kubernetes-dev@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/2bdc0478-3465-407f-b591-c9661dac7939%40googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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 kubernetes-dev+unsubscribe@googlegroups.com.
>> To post to this group, send email to kubernetes-dev@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/kubernetes-dev/CAHv71zLdBejS3eA4YVA14WsmVXj-4HFG%3DUeA7PJzPc9gJ9Nfvg%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CAHf_GkDb-sMc61_XcMzdvQ1RSB-f88gg5OE5u9fRvc0bXWM0XA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewbyKo6yq1qfaxCKWktg-978Shhv7z2hx%2BN-b%2BLhfKXZYQ%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages