-
Notifications
You must be signed in to change notification settings - Fork 147
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
Add Spotlight Blog for SIG Release - Release Team Subproject #424
Add Spotlight Blog for SIG Release - Release Team Subproject #424
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nits, of which a couple are debatable and can be improved upon. I do think that the underlying reason they exist is sound though.
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
b08fef6
to
cd1dbfd
Compare
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-overview.png
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
Update: Ready for the next set of review. |
There are still some unresolved suggestions. Some are open to further debate, others are about clerical errors (like the one pointed out by @sftim above) which are more straightforward - so much so that if you agree with the changes, it would be simpler in the future to accept the suggestions on GitHub since that provides an easier way to track them (not now, since they were marked out of date), and would've resolved this particular one - additionally, it updates the commit authors with those reviewing, something which is also possible when you do the final squash but doing it "by hand" is harder. Apart from that, the images are a nice touch and I think the interview is quite interesting, so I think that with the open points resolved this is good to go, great work! |
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
@nitishfy , I have added suggestions, one of them is due to new content, the other is to address the spelling of one word (already discussed). Please go through the open comments, there's one on the need for 100 char limit as well. All discussion points should be resolved (not necessarily changed). We're getting there though! |
I'm afraid why doesn't the preview show this blog? :( |
Does this preview OK locally? (run |
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
|
||
Before you read further, it is important to note that there are two subprojects under SIG Release, _Release Engineering_ and _Release Team_. | ||
|
||
In this blog post, [Nitish Kumar](https://twitter.com/Nitishtwt06) interviews Verónica López(PlanetScale), Technical Lead of SIG Release with the spotlight on the Release Team subproject, how the release process looks like, and ways to get involved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this blog post, [Nitish Kumar](https://twitter.com/Nitishtwt06) interviews Verónica López(PlanetScale), Technical Lead of SIG Release with the spotlight on the Release Team subproject, how the release process looks like, and ways to get involved. | |
In this blog post, [Nitish Kumar](https://twitter.com/Nitishtwt06) interviews Verónica López(PlanetScale), | |
Technical Lead of SIG Release with the spotlight on the Release Team subproject, | |
how the release process looks like, and ways to get involved. |
"Please wrap the Markdown source at, say, 100 characters per line."
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the article.
I can see the intent to number sections. Markdown can do that for us and I think we should take advantage - see https://www.google.com/search?q=how+do+ordered+lists+work+in+Markdown or check your own preferred guide to the syntax.
I have added some other inline feedback; several of these are things I do recommend fixing before we publish.
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
Once the comments from #424 (review) are fixed, I'll get a mirror PR opened against the main Kubernetes blog. |
we already have an ordered list in the form of questions. |
Sorry, I may be missing something. That sentence doesn't make any sense to me in the context. Can you explain what you mean @nitishfy ? |
Could you explain what you mean here to number sections? If we are mentioning about numbering the questions that have been asked, it has already been marked. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, typo here: “Stabalization” should be “Stabilization”.
(nit)
“Here's KEP” should be “Here's a KEP”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding this "“Here's KEP” should be “Here's a KEP”, I made the picture on excalidraw and don't have it anymore which means the diagram can't me modified. Do you have an other option for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge it without fixing that typo, and after it merges I'll see if I can find someone who can edit the image.
content/en/blog/2023/sig-release-spotlight/sig-release-spotlight.md
Outdated
Show resolved
Hide resolved
Squashed the commits. |
9e91294
to
8fa4e92
Compare
**1. What is the typical release process for a new version of Kubernetes, from initial planning | ||
to the final release? Are there any specific methodologies and tools that you use to ensure a smooth release?** | ||
|
||
The release process for a new Kubernetes version is a well-structured and community-driven | ||
effort. There are no specific methodologies or | ||
tools as such that we follow, except a calendar with a series of steps to keep things organised. | ||
The complete release process looks like this: | ||
|
||
- **Release Team Onboarding:** We start with the formation of a Release Team, which includes | ||
volunteers from the Kubernetes community who will be responsible for managing different | ||
components of the new release. This is typically done before the previous release is about to | ||
wrap up. Once the team is formed, new members are onboarded while the Release Team Lead and | ||
the Branch Manager propose a calendar for the usual deliverables. As an example, you can take a look at [the v1.29 team formation issue](https://github.com/kubernetes/sig-release/issues/2307) created at the SIG Release | ||
repository. For a contributor to be the part of Release Team, they typically go through the | ||
Release Shadow program, but that's not the only way to get involved with SIG Release. | ||
|
||
- **Beginning Phase:** In the initial weeks of each release cycle, SIG Release diligently | ||
tracks the progress of new features and enhancements outlined in Kubernetes Enhancement | ||
Proposals (KEPs). While not all of these features are entirely new, they often commence | ||
their journey in the alpha phase, subsequently advancing to the beta stage, and ultimately | ||
attaining the status of stability. | ||
|
||
- **Feature Maturation Phase:** We usually cut a couple of Alpha releases, containing new | ||
features in an experimental state, to gather feedback from the community, followed by a | ||
couple of Beta releases, where features are more stable and the focus is on fixing bugs. Feedback | ||
from users is critical at this stage, to the point where sometimes we need to cut an | ||
additional Beta release to address bugs or other concerns that may arise during this phase. Once | ||
this is cleared, we cut a _release candidate_ (RC) before the actual release. Throughout | ||
the cycle, efforts are made to update and improve documentation, including release notes | ||
and user guides, a process that, in my opinion, deserves its own post. | ||
|
||
- **Stabilization Phase:** A few weeks before the new release, we implement a _code freeze_, and | ||
no new features are allowed after this point: this allows the focus to shift towards testing | ||
and stabalisation. In parallel to the main release, we keep cutting monthly patches of old, | ||
officially supported versions of Kubernetes, so you could say that the lifecycle of a Kubernetes | ||
version extends for several months afterwards. Throughout the complete Release cycle, efforts | ||
are made to update and improve documentation, including release notes and user guides, a | ||
process that, in our opinion, deserves its own post. | ||
<figure> | ||
<img src="/blog/2023/sig-release-spotlight/sig-release-overview.png" alt="sig-release-overview"></img> | ||
</figure> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify #424 (review), here's an example of numbering using Markdown:
**1. What is the typical release process for a new version of Kubernetes, from initial planning | |
to the final release? Are there any specific methodologies and tools that you use to ensure a smooth release?** | |
The release process for a new Kubernetes version is a well-structured and community-driven | |
effort. There are no specific methodologies or | |
tools as such that we follow, except a calendar with a series of steps to keep things organised. | |
The complete release process looks like this: | |
- **Release Team Onboarding:** We start with the formation of a Release Team, which includes | |
volunteers from the Kubernetes community who will be responsible for managing different | |
components of the new release. This is typically done before the previous release is about to | |
wrap up. Once the team is formed, new members are onboarded while the Release Team Lead and | |
the Branch Manager propose a calendar for the usual deliverables. As an example, you can take a look at [the v1.29 team formation issue](https://github.com/kubernetes/sig-release/issues/2307) created at the SIG Release | |
repository. For a contributor to be the part of Release Team, they typically go through the | |
Release Shadow program, but that's not the only way to get involved with SIG Release. | |
- **Beginning Phase:** In the initial weeks of each release cycle, SIG Release diligently | |
tracks the progress of new features and enhancements outlined in Kubernetes Enhancement | |
Proposals (KEPs). While not all of these features are entirely new, they often commence | |
their journey in the alpha phase, subsequently advancing to the beta stage, and ultimately | |
attaining the status of stability. | |
- **Feature Maturation Phase:** We usually cut a couple of Alpha releases, containing new | |
features in an experimental state, to gather feedback from the community, followed by a | |
couple of Beta releases, where features are more stable and the focus is on fixing bugs. Feedback | |
from users is critical at this stage, to the point where sometimes we need to cut an | |
additional Beta release to address bugs or other concerns that may arise during this phase. Once | |
this is cleared, we cut a _release candidate_ (RC) before the actual release. Throughout | |
the cycle, efforts are made to update and improve documentation, including release notes | |
and user guides, a process that, in my opinion, deserves its own post. | |
- **Stabilization Phase:** A few weeks before the new release, we implement a _code freeze_, and | |
no new features are allowed after this point: this allows the focus to shift towards testing | |
and stabalisation. In parallel to the main release, we keep cutting monthly patches of old, | |
officially supported versions of Kubernetes, so you could say that the lifecycle of a Kubernetes | |
version extends for several months afterwards. Throughout the complete Release cycle, efforts | |
are made to update and improve documentation, including release notes and user guides, a | |
process that, in our opinion, deserves its own post. | |
<figure> | |
<img src="/blog/2023/sig-release-spotlight/sig-release-overview.png" alt="sig-release-overview"></img> | |
</figure> | |
1. **What is the typical release process for a new version of Kubernetes, from initial planning | |
to the final release? Are there any specific methodologies and tools that you use to ensure a smooth release?** | |
The release process for a new Kubernetes version is a well-structured and community-driven | |
effort. There are no specific methodologies or | |
tools as such that we follow, except a calendar with a series of steps to keep things organised. | |
The complete release process looks like this: | |
- **Release Team Onboarding:** We start with the formation of a Release Team, which includes | |
volunteers from the Kubernetes community who will be responsible for managing different | |
components of the new release. This is typically done before the previous release is about to | |
wrap up. Once the team is formed, new members are onboarded while the Release Team Lead and | |
the Branch Manager propose a calendar for the usual deliverables. As an example, you can take a look | |
at [the v1.29 team formation issue](https://github.com/kubernetes/sig-release/issues/2307) created at the SIG Release | |
repository. For a contributor to be the part of Release Team, they typically go through the | |
Release Shadow program, but that's not the only way to get involved with SIG Release. | |
- **Beginning Phase:** In the initial weeks of each release cycle, SIG Release diligently | |
tracks the progress of new features and enhancements outlined in Kubernetes Enhancement | |
Proposals (KEPs). While not all of these features are entirely new, they often commence | |
their journey in the alpha phase, subsequently advancing to the beta stage, and ultimately | |
attaining the status of stability. | |
- **Feature Maturation Phase:** We usually cut a couple of Alpha releases, containing new | |
features in an experimental state, to gather feedback from the community, followed by a | |
couple of Beta releases, where features are more stable and the focus is on fixing bugs. Feedback | |
from users is critical at this stage, to the point where sometimes we need to cut an | |
additional Beta release to address bugs or other concerns that may arise during this phase. Once | |
this is cleared, we cut a _release candidate_ (RC) before the actual release. Throughout | |
the cycle, efforts are made to update and improve documentation, including release notes | |
and user guides, a process that, in my opinion, deserves its own post. | |
- **Stabilisation Phase:** A few weeks before the new release, we implement a _code freeze_, and | |
no new features are allowed after this point: this allows the focus to shift towards testing | |
and stabilisation. In parallel to the main release, we keep cutting monthly patches of old, | |
officially supported versions of Kubernetes, so you could say that the lifecycle of a Kubernetes | |
version extends for several months afterwards. Throughout the complete release cycle, efforts | |
are made to update and improve documentation, including release notes and user guides, a | |
process that, in our opinion, deserves its own post. | |
{{< figure src="/blog/2024/sig-release-spotlight/sig-release-overview.png" caption="SIG Release overview" alt="Release team onboarding; beginning phase; stabalization phase; feature maturation phase" >}} |
I left the typo in the alt attribute as I heard that we don't have an easy way to draw a different image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge it without fixing that typo, and after it merges I'll see if I can find someone who can edit the image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we're in a new year, some of the image paths need to change.
content/en/blog/2023/sig-release-spotlight/sig-release-meetings.png
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-motivation.png
Outdated
Show resolved
Hide resolved
content/en/blog/2023/sig-release-spotlight/sig-release-overview.png
Outdated
Show resolved
Hide resolved
fix deploy preview and markdown wrap Signed-off-by: NitishKumar06 <justnitish06@gmail.com> publish date updated Signed-off-by: NitishKumar06 <justnitish06@gmail.com> address minor comments Signed-off-by: NitishKumar06 <justnitish06@gmail.com> address minor comments Signed-off-by: NitishKumar06 <justnitish06@gmail.com>
Signed-off-by: NitishKumar06 <justnitish06@gmail.com>
8fa4e92
to
50e1fc7
Compare
I think we're ready to merge this PR now |
Thanks for the PR. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nitishfy, sftim 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 |
/hold cancel |
FYI, we need to add a PR under |
Yes, with the reviewed content, and the small changes needed (mainly header tags and the author indication). |
Spotlight blog for the SIG-Release - Release Team Subproject.