/sig release architecture

/assign

/milestone v1.27

/stage stable

Hello @liggitt 👋, v1.27 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PDT Thursday 9th February 2023.

This enhancement is targeting for stage alpha for 1.27 (please correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.27
• KEP readme has a updated detailed test plan section filled out
• KEP readme has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

For this KEP, we would need to update the following:

• Update to the latest KEP template; assuming the current state of KEP-3744: Stay on supported go versions: initial draft #3749 there is a missing topic in the PRR Scalability about resource exhaustion, there could be more.
• The PRR review is linked with the previous one, once that additional section is covered it will be done.
• Update kep.yaml to reflect current stage information. This is covered in KEP-3744: Stay on supported go versions: initial draft #3749
• Update the test plan. Covered in KEP-3744: Stay on supported go versions: initial draft #3749

The status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

The linked PR has lgtm/approve from sig approvers, shadow PRR is complete and it's waiting for an ack from @johnbelamaric.

• there is a missing topic in the PRR Scalability about resource exhaustion

This KEP is a process KEP, so the answer to almost every PRR question is "no" or "n/a", but sure, I pushed an update to add the new question.

As an aside, I copied the KEP template on January 17th... it looks like the template was modified to add that question about a week ago in #3783. It's very frustrating to make the questions that need answering a moving target a handful of days before enhancements freeze. @wojtek-t, would it be possible for PRR to batch updates to the KEP template by the .0 release, to avoid churn for folks working on KEPs for the upcoming release (and avoid churn for release folks checking bookkeeping for every KEP for the upcoming release)?

@liggitt I missed that question as well, to be honest, so I was also caught off-guard since the KEPs I was reviewing seemed to be up-to-date, this is why I explicitly mentioned that question, it was indeed not present even if KEPs that were done very recently :( Thank you for adding that question, that covers everything once #3749 is merged (but I will take another look then).

@fsmunoz - #3749 is merged, can you confirm this meets requirements to be tracked for 1.27?

Hi @liggitt , thank you for your work on this.

Here's where this enhancement currently stands (and this is for stable, it was erroneously described as alpha before);

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.27
• KEP readme has a updated detailed test plan section filled out
• KEP readme has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

This being a process enhancement, I'm assuming (with the information I have right now) that the graduation and PRR are perfectly adequate as-is, since this is either done or not done. With that, I'm marking this as meeting all the requirements to be tracked for v1.27.

Thanks!

/label tracked/yes
/remove-label tracked/no

@fsmunoz: Those labels are not set on the issue: tracked/no

/approve

Hi @liggitt 👋,

Checking in as we approach 1.27 code freeze at 17:00 PDT on Tuesday 14th March 2023.

Please ensure the following items are completed:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
• All PRs are fully merged by the code freeze deadline.

• Add optional go compatibility unit and integration presubmits test-infra#28626
• Automate setup of go-compatibility unit and integration variants test-infra#28892

For this enhancement, it looks like all linked PRs are merged; there are however two additional tasks in the Code sections, but without associated PRs - if they have PRs and they are not merged, then this status is not up-to-date and conditions for code freeze might be missing.

Please let me know what other PRs in k/k I should be tracking for this KEP.

As always, we are here to help should questions come up. Thanks!

there are no code changes for k/k remaining, the rest of the work is around release process docs and project policy docs

I updated the description to make that clearer

@marosset can you modify the milestone in the 1.27 tracking project to stable for this process change?

@marosset can you modify the milestone in the 1.27 tracking project to stable for this process change?

done!

@liggitt was there a Docs PR opened against dev-1.27 branch in the k/website repo?

If not, please take a look at Documenting for a release - PR Ready for Review to get your PR ready for review as soon as possible. 01:00 UTC Wednesday 22nd March 2023 / 17:00 PDT Tuesday 21st March 2023 is the official deadline.

This PR will need a doc review by Tuesday 4th April 2023 to get this into the release. Please reach out to required SIGs to get their review. Thank you!

As mentioned in #3744 (comment), this is a policy KEP not tied to the v1.27.0 release. The remaining docs are to release handbooks and policy docs. I'm working on those but they are detached from the release cut, so I wouldn't expect them to be against the website repo or the dev-1.27 branch

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten