-
Notifications
You must be signed in to change notification settings - Fork 384
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 release-1.32 team and timeline #2604
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: fsmunoz The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retitle Add release-1.32 team and timeline |
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.
Major Themes is now Release Highlights, as of #2600 (yay!)
Co-authored-by: Kat Cosgrove <kat.cosgrove@gmail.com>
Thank you @katcosgrove ! |
releases/release-1.32/README.md
Outdated
| Release blog ready to review | Comms / Docs | 02:00 UTC Wednesday 20th November 2024 / 19:00 PDT Tuesday 19th November 2024 | week 11 | | | ||
| Feature blogs ready to review | Enhancement Owner / SIG Leads | Friday 22nd November 2024 | week 11 | | | ||
| Burndown Meetings daily (Tuesday & Thursday over Slack) | Lead | Monday 25th November 2024 | week 12 | | | ||
| [**Test Freeze**] | Branch Manager | 01:00 UTC Wednesday 27th November 2024 / 19:00 PDT Tuesday 26th November 2024 | week 12 | | |
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.
During 1.31 cut we discussed eliminating a distinct test freeze, and requiring stable test coverage be in place by code freeze. Fixes for test failures would still be accepted (just as they are today), but having a separate official test freeze date invites unstable or insufficient tests for code added before code freeze.
cc @johnbelamaric @BenTheElder @dims @thockin @Verolop @jeremyrickard @jpbetz @soltysh
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.
I think that would just mean dropping this line and making the existing code freeze date the "code and test freeze" (or moving the "code and test freeze" date to this line)
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.
+1, I think in retrospect test freeze has not been a helpful concept, and test fixes should be treated the same as bug fixes post-freeze, but whole new tests should not be deferred and ideally implementation PRs should have tests to begin with.
Test-freeze encourages punting tests and we've even wound up with beta features that are not sufficiently tested due to deferred test work.
We could allow some additional time for code freeze into at least part of the test freeze window.
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.
+1 to just dropping the line and rolling it into code freeze. @BenTheElder is your suggestion to delay the code freeze period (shorten it?)
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.
We can do one of:
- drop the test freeze date and roll it into the code freeze date
- drop the code freeze date and roll it into what was the test freeze date
- something in-between
Jordan had raised some concerns about 2), roughly that it means we have less time focused on stabilization.
3) might make sense, which is what I attempted to bring up, but for this release we also have #2604 (comment) to consider (kubecon / freeze alignment ...)
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.
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.
👍 for dropping the test freeze
releases/release-1.32/README.md
Outdated
| **Begin [Burndown]** (Monday, Wednesday, and Friday meetings) | Lead | Monday 18th November 2024 | week 11 | | | ||
| Release Highlights deadline | Comms | Tuesday 19th November 2024 | week 11 | | | ||
| Start final draft of Release Notes | Release Notes Lead | Tuesday 19th November2024 | week 11 | | | ||
| **Begin [Code Freeze]** | Branch Manager | 02:00 UTC Wednesday 20th November 2024 / 19:00 PDT Tuesday 19th November 2024 | week 11 | | |
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.
This is ~2 business days after kubecon. Speaking for myself, time for code reviews the previous week will be extremely scarce. If we put code freeze immediately after kubecon like this, we have to communicate super well that PRs not merged by start of kubecon could be ~high risk of missing, depending on who the reviewers / implementers are.
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.
I would rather move the code freeze before Kubecon, than give false hopes to contributors.
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.
I would also vote to move this to before KubeCon. It also looks like we have docs deadlines during KubeCon. I would suggest both of these be week of Nov 4th. Perhaps also move the beta back? That would be a week between the third alpha release and the beta release. I am not sure we need more than that based on how much feedback we typically get from them...but moving the beta back a week allows people to find issues that can be fixed ahead of code freeze.
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.
Thank you! Would something like this work:
- Begin Feature blog freeze: Oct 30 (w8)
- 1.32.0-beta.0 release: Nov 5 (w9)
- Begin Code Freeze & Test Freeze: Nov 8 (w9)
- Docs deadline - PRs ready for review: Nov 18 (w11)
KubeCon NA is Nov 12-15, so this would anticipate beta-0
1 week, and put the freeze before KubeCon. Docs deadline could be on Nov 8 as well: I've suggested here to delay it one week instead of anticipating it.
The distance between beta-0
and the freeze is shorter, and exception requests will appear on KubeCon week, but from what I've read here these are minor compared with the benefit of having the freeze before KubeCon.
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.
I've committed a new version that reflects this approach, essentially compressing things a bit more to put deadlines before KubeCon, plus merging Code and Test Freeze.
releases/release-1.32/README.md
Outdated
| Feature blogs ready to review | Enhancement Owner / SIG Leads | Friday 22nd November 2024 | week 11 | | | ||
| Burndown Meetings daily (Tuesday & Thursday over Slack) | Lead | Monday 25th November 2024 | week 12 | | | ||
| [**Test Freeze**] | Branch Manager | 01:00 UTC Wednesday 27th November 2024 / 19:00 PDT Tuesday 26th November 2024 | week 12 | | | ||
| release-1.32 branch created | Branch Manager | Tuesday 26th November 2024 | week 12 | | |
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.
This is also a holiday week in the US, so we should work early to make sure we have review coverage outside the US in terms of release managers.
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.
Thanksgiving week is 25-29, the problem I see with delaying things is that it could move the release date to week 15, which is closer to Christmas (also typically a period where vacations/holidays are a concern), but it's doable e.g.:
- Move release date to Dec 18th
- Move Docs Freeze to Dec 3rd
- Move
rc-1
to Dec 10
... and adjust the rest, giving more days for the "ready to review" ones.
Or we could just keep it as is and prepare for it, as you mentioned @jeremyrickard .
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.
I don't think I would delay at all. My comment was more just that we should prepare and make sure folks are lined up, and informational for any potential release manager shadows.
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.
Understood, will make sure that that is properly relayed to everyone.
releases/release-1.32/README.md
Outdated
| Docs deadline — PRs ready for review | Docs Lead | Tuesday 12th November 2024 | week 10 | | | ||
| Deprecations and Removals blog published | Comms | Thursday 14th November 2024 | week 10 | | | ||
| **Begin [Burndown]** (Monday, Wednesday, and Friday meetings) | Lead | Monday 18th November 2024 | week 11 | | | ||
| Release Highlights deadline | Comms | Tuesday 19th November 2024 | week 11 | | |
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.
The Release Highlights process is still unclear to me (respect to the former Major Themes) so I cannot validate this deadline yet.
releases/release-1.32/README.md
Outdated
| **Production Readiness Freeze** | Enhancements Lead | Thursday 3rd October 2024 | week 4 | | | ||
| Begin Friday APAC-friendly meetings | Lead | Wednesday 9th October 2024 | week 5 | | | ||
| **Begin [Enhancements Freeze]** | Enhancements Lead | 02:00 UTC Friday 11th October 2024 / 19:00 PDT Thursday 10th October 2024 | week 5 | [master-blocking], [master-informing] | | ||
| 1.32.0-alpha.2 released | Branch Manager | Tuesday 15th October 2024 | week 6 | | |
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.
On week 6 I would add a (soft) deadline for blog opt-ins.
The rationale behind this is to minimize the number of reachouts to KEP owners that are not interested in writing a blog but end up saying so only later in the process.
I would even add two questions in the template PR
"Do you think that this feature requires a blog? If so, are you willing to write one?"
Just an idea, feel free to discard this if you think it's not feasible.
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.
We've had that discussion (at least partially) in the 1.26 retro - I remember it because I suggested something like that:
The deadlines for Feature Blogs are difficult to track and provide a status on: they are viewed as the day in which things need to be pushed, which makes it very hard to provide a status update since 80% of placeholder PRs arrive in the last 2 days. If we want to have realistic RAG (Red, Amber, Green) status for Comms, perhaps we should adopt a “soft” deadline and a “hard” one, or something else like a “rolling window” in which things get added at the end (we used this for 1 blog this release
The consensus was that "soft deadlines" do not exist, and every time they were used they were either perceived as "hard", or no deadline at all.
Interesting idea on adding the opt-in to the PR, would like to hear more opinions on it (I'm not sure if it's doable for this release from a practical perspective).
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.
So my idea would be to have those questions directly here: https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/enhancement.yaml
Since the enhancement tracking is done mainly for release purposes, adding a box with these questions seems reasonable. It would save an entire cycle of reachouts for whoever says directly "no, this enhancement won't have a blog" from the start. Wdyt?
I'm also ok with adding a hard deadline for the opt in on the 6th week but conscious that it probably won't be treated as such due to the nature of blogging/content creation in general.
Co-authored-by: Tim Allclair <timallclair@gmail.com>
Co-authored-by: Sascha Grunert <sgrunert@redhat.com>
Co-authored-by: Sascha Grunert <sgrunert@redhat.com>
Initial v1.32 release information: