diff --git a/.github/ISSUE_TEMPLATE/release-team-lead-progress.md b/.github/ISSUE_TEMPLATE/release-team-lead-progress.md index 35cc3b63c17..d0a5fcf889a 100644 --- a/.github/ISSUE_TEMPLATE/release-team-lead-progress.md +++ b/.github/ISSUE_TEMPLATE/release-team-lead-progress.md @@ -1,7 +1,7 @@ --- name: Release Team Lead Cycle Progress about: Used to track release lead work which needs to be done every release cycle -title: '[1.XX] Release Team Lead Cycle Progress' +title: '[v1.XX] Release Team Lead Cycle Progress' labels: sig/release, area/release-eng, area/release-team --- @@ -17,7 +17,13 @@ The issue should be kept open for the entirety of the release cycle, until all t * Release Lead Shadow: (at)USERNAME * Release Lead Shadow: (at)USERNAME * Release Lead Shadow: (at)USERNAME -* Release Cycle: `Kubernetes 1.XX` +* Subteam Leads + * Enhancements Lead: (at)USERNAME + * Documentation Lead: (at)USERNAME + * Release Signal Lead: (at)USERNAME + * Communications Lead: (at)USERNAME + * Branch Manager: (at)USERNAME +* Release Cycle: `Kubernetes v1.XX` * [Release Timeline](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.XX) Additional information can be found in the [release team lead handbook](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/release-team-lead). If tasks are not needed to be done or additional tasks are required, make sure to update the issue template! @@ -28,37 +34,43 @@ Additional information can be found in the [release team lead handbook](https:// - [ ] Captured feedback from previous release cycle retro and planned to incorporate it into the release cycle - [ ] Release directory named `release-1.XX` added to [k/sig-release/releases](https://github.com/kubernetes/sig-release/tree/master/releases) +- [ ] Pruned the OWNERS file from the previous release cycle in [k/sig-release/releases/release-1.XX](https://github.com/kubernetes/sig-release/tree/master/releases) - [ ] Started planning the release schedule by opening a thread in `#sig-release` - [ ] Release Lead Shadows are confirmed - [ ] Team leads notified that all release team members read the [release team onboarding document](https://github.com/kubernetes/sig-release/blob/master/release-team/release-team-onboarding.md) - [ ] Update slack channel descriptions for the `#sig-release` channel and all `#release-xxx` channels **Release Lead Onboarding:** -- [ ] Release Team Lead has agreed to abide by the guidelines set forth in the - [Security Release Process](https://git.k8s.io/security/security-release-process.md), specifically the embargo on CVE communications. - This must be done as an issue comment by the incoming Release Team Lead. +- [ ] Release Team Lead, Lead Shadows, and Subteam Leads have agreed to abide by the guidelines set forth in the + [Security Release Process](https://git.k8s.io/security/security-release-process.md), specifically the embargo on CVE communications. + This must be done as an issue comment by each of the above named individuals. +- [ ] Release Team Lead, Lead Shadows, and Subteam Leads have been through Linux Foundation Training - LFC101 or LFC102 and have shared their certificate of completion in the issue comments. - [ ] Updated GitHub teams [(`kubernetes/org`)](https://git.k8s.io/org/config/kubernetes/sig-release/teams.yaml) - `milestone-maintainers` - `release-team` - `release-team-leads` - - `sig-release` -- [ ] Updated `kubernetes/sig-release` `OWNERS` - - Release Team Lead and Shadows - - Add an `approvers` entry in `releases/release-1.XX/OWNERS` - - **Release Team Lead only** - - In `OWNERS_ALIASES`, add an entry in the following sections: - - `release-team` - - `release-team-lead-role` + - `release-team-XX` (where XX is the release role, e.g. `release-team-enhancements`, `release-team-docs`, etc) +- [ ] Updated `kubernetes/sig-release` `OWNERS_ALIASES` + - `release-team-lead` - release lead + - `release-team-lead-shadows` - release lead shadows + - `communications-subteam-approvers` - communications lead + - `docs-subteam-approvers` - docs lead + - `enhancements-subteam-approvers` - enhancements lead + - `release-signal-subteam-approvers` - release signal lead - [ ] Updated Google Groups/GCP IAM membership [(`kubernetes/k8s.io`)](https://git.k8s.io/k8s.io/groups/groups.yaml) - `k8s-infra-release-viewers@` + - `release-comms@` - `release-managers@` - `release-team@` + - `release-team-shadows@` + - `k8s-infra-staging-tg-exporter@` + - `release-team-enhancements@` - [ ] Release Team calendar access granted (reach out to sig-release chairs) - [ ] Zoom credentials (host key) granted (reach out to sig-release chairs) - [ ] Added incoming release team leads to `release-team-leads` Slack Group [(`kubernetes/community`)](https://git.k8s.io/community/communication/slack-config/sig-release/usergroups.yaml) - Add slack ID(s) to [`users.yaml`](https://git.k8s.io/community/communication/slack-config/users.yaml), if they are not yet in the file - Add username(s) to [`usergroups.yaml`](https://git.k8s.io/community/communication/slack-config/sig-release/usergroups.yaml) -- [ ] Ensured the Release Team subproject owners are the owners of the [kubernetes-release-team-shadows](https://groups.google.com/a/kubernetes.io/g/release-team-shadows) Google Group. +- [ ] Ensured the Release Team subproject owners are the owners of the [release-team-shadows](https://groups.google.com/a/kubernetes.io/g/release-team-shadows) Google Group at [(`kubernetes/k8s.io`)](https://git.k8s.io/k8s.io/groups/groups.yaml) - [ ] Ensured top-level `OWNERS_ALIASES` only includes Release Team personnel from four (4) releases, including the current one. **Create Release Team Documents:** @@ -77,7 +89,7 @@ Additional information can be found in the [release team lead handbook](https:// - Access: : **restricted access**, edit rights shared with release team lead shadows individually **One week before the start of the release cycle:** -- [ ] "Release Sneak Peak" email to introduce yourself, lead shadows, role leads, and branch manager has been send out +- [ ] "Release Sneak Peak" email to introduce yourself, lead shadows, role leads, and branch manager has been sent out - Send the email to [k-dev](https://groups.google.com/a/kubernetes.io/g/dev), [SIG Leads](https://groups.google.com/a/kubernetes.io/g/leads), [SIG Release](https://groups.google.com/forum/#!forum/kubernetes-sig-release), [Release Team](https://groups.google.com/a/kubernetes.io/g/release-team) - Example: [1.26 sneak peek](https://groups.google.com/a/kubernetes.io/g/dev/c/PVe1OG8yjHw/m/zZjnttXWAQAJ) @@ -94,23 +106,25 @@ Additional information can be found in the [release team lead handbook](https:// - [ ] Request review of this document by the Release Team Lead shadow(s). The shadow(s) should also take all actions in this document around joining groups and requesting access permissions. - [ ] Update the SIG Release groups in the `k/k8s.io/groups/sig-release/groups.yaml` with the following: - [ ] Add Lead and Lead shadows to members of `k8s-infra-release-viewers` - - [ ] Add EA, Lead, Lead shadows, comms lead, comms shadows to members of `release-comms` - - [ ] Add EA, Lead and Lead shadows to members of `release-managers` - - [ ] Add EA, Lead and Lead shadows to managers of `release-team` + - [ ] Add Lead, Lead shadows, comms lead, comms shadows to members of `release-comms` + - [ ] Add Lead and Lead shadows to members of `release-managers` + - [ ] Add Lead and Lead shadows to managers of `release-team` - [ ] Add Role Leads and Role shadows to members of `release-team` - [ ] Add Role shadows and Lead shadows to members of `release-team-shadows` - - [ ] Add EA to manager of release-team-shadows, if EA is owner of `release-team-shadows` already then add Lead to manager of `release-team-shadows` -- [ ] Ensured that there is a branch manager available for cutting 1.XX.0-alpha.1 + - [ ] Add Lead to manager of `release-team-shadows` - Assist the Enhancements Lead in collecting planned work from SIGs - [ ] Discussed and scheduled a weekly Release Team meetings on a day that is most acceptable to the team. Invite the `kubernetes-sig-release` group. - [ ] Update the release calendar with the initial release meeting times and dates set to UTC. - [ ] Poll Release Team membership and schedule a weekly alternate meeting to better enable more attendance outside of the Americas. - [ ] Major release cycle events have been added to the Kubernetes Release Calendar with one week in advance reminders set. (defer to the [handbook for more information](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/release-team-lead#working-with-the-release-team-calendar)) -- [ ] Checked in with ci-signal and branch managers if 1.XX.0-alpha.2 is ok to be released and [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) tests are all green + +**Release Cut Alpha 1:** +- [ ] Checked in with release-signal and branch managers if 1.XX.0-alpha.1 is ok to be released and [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) tests are all green +- [ ] Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.1 is generated **A week before Enhancements Freeze:** -- [ ] Remind the community about Enhancements Freeze reminder send out. Example email: [1.26](https://groups.google.com/a/kubernetes.io/g/dev/c/pJZC2cnkeJ8); It may also be useful to send a short version to the `#sig-release` and `#chairs-and-techleads` Slack channels referencing to the k-dev email. +- [ ] Remind the community about Enhancements Freeze reminder sent out. Example email: [1.26](https://groups.google.com/a/kubernetes.io/g/dev/c/pJZC2cnkeJ8); It may also be useful to send a short version to the `#sig-release` and `#chairs-and-techleads` Slack channels referencing to the k-dev email. ### 3. Enhancements freeze up to Release Halfway Point (~Week 5 - 7) @@ -120,49 +134,40 @@ Additional information can be found in the [release team lead handbook](https:// - [ ] Release Team Retro is scheduled shortly after the "Release Halfway Point" and a host is selected - [ ] Make sure everyone knows the Docs deadline (PRs ready for review) is coming the following week. (around week 6) -**Release Cut Alpha 3:** -- [ ] Checked in with ci-signal and branch managers if 1.XX.0-alpha.3 is ok to be released and [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) tests are all green -- [ ] Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.3 is generated +**Release Cut Alpha 2:** +- [ ] Checked in with release-signal and branch managers if 1.XX.0-alpha.2 is ok to be released and [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) tests are all green +- [ ] Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.2 is generated -**Release Cut Alpha 4:** -- [ ] Checked in with ci-signal and branch managers if 1.XX.0-alpha.4 is ok to be released and [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) tests are all green -- [ ] Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.4 is generated +**Removals, Deprecations, and Major Changes Blog:** +- [ ] Check in with release-comms if they are in contact with the release-enhancements team to collect "deprecations and removals" targeting the release +- [ ] Identified with release-comms & sig-docs if a "Removals, Deprecations, and Major Changes" blog is needed and if so, started drafting it up (ref [1.26 blog](https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/)) +- [ ] Check with release-comms if they need help gathering "deprecations, removals and major changes" for the release. If so, assign KEPs to release lead shadows to collect this information from SIGs or identify highlight-worthy items themselves. ### 4. Release Halfway Point up to Code Freeze (~Week 8 - 11) +**Release Cut Alpha 3:** +- [ ] Checked in with release-signal and branch managers if 1.XX.0-alpha.3 is ok to be released and [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) tests are all green +- [ ] Checked in with Docs team on release notes progress after the tag for 1.XX.0-alpha.3 is generated + **General Tasks:** - [ ] Send out a "Release Update / State of the Release", example: [1.26](https://groups.google.com/a/kubernetes.io/g/dev/c/_nToVaHVN1Q) - [ ] Notify SIGs and about upcoming Code Freeze Deadline by sending an email to the [kubernetes-dev](https://groups.google.com/a/kubernetes.io/g/dev) list -- [ ] The first retrospective meeting is scheduled for the first week of Monday, Wednesday, and Friday burndown meetings, typically mid-week. Confirm the Emeritus Adviser can serve as facilitator. If Emeritus Adviser is unavailable then defer the responsibility as appropriate. +- [ ] The first retrospective meeting is scheduled for the first week of Monday, Wednesday, and Friday burndown meetings, typically mid-week. Confirm the release team subproject owner can serve as facilitator. If the subproject owner is unavailable then defer the responsibility as appropriate. - [ ] Make sure everyone knows the Docs deadline (PRs ready for review) is coming the following week. - [ ] Started release team meetings on Monday, Wednesday, and Friday - [ ] Pinged role leads reminding them to start considering succession plans. If they are handing the role off to a successor, identifying them early gives more time for the committed volunteer to get targeted mentoring. +- [ ] Checked in with lead shadows and their assigned subteams to ensure they are on track with their responsibilities. **Removals, Deprecations, and Major Changes Blog:** -- [ ] Check in with release-comms if they are in contact with the release-enhancements team to collect "deprecations and removals" targeting the release -- [ ] Identified with release-comms & sig-docs if a "Removals, Deprecations, and Major Changes" blog is needed and if so, started drafting it up (ref [1.26 blog](https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/)) - [ ] A Release Team representative (ideally from release-comms) should attend the sig-docs meeting to raise awareness about the "Deprecations and Removals blog" for reviews. - [ ] The Deprecations and Removals blog is scheduled for next week shortly after Code Freeze. A draft of the blog should be started as reviews and iterations will be needed before publication next week -- [ ] Insured that "Removals, Deprecations, and Major Changes"-authors are reviewing the blog before it's being publicized +- [ ] Ensured that "Removals, Deprecations, and Major Changes"-authors are reviewing the blog before it's being publicized **Release Highlights & Release Blog:** - [ ] Followed up with SIGs on the release highlights of the release - [ ] Checked in with release-comms about the status of release highlights collection -### 5. Around Docs Freeze (~Week 12) -Defer to the [Docs Freeze section in the release-team-lead handbook](#). - -#### Shortly before Docs Freeze -- [ ] Monitor the docs tab of the enhancements GitHub project to get an idea of how many PRs are still outstanding leading up to Docs Freeze. -- [ ] Make sure everyone knows Docs Freeze is coming the following week. (week 12) - -#### Week of Docs Freeze -- [ ] As needed, assist the Docs subteam lead with any last-minute escalations. - -#### After Docs Freeze -- [ ] Bring exceptions to the **#sig-release** Slack channel, start a thread for each, and ensure SIG representatives for the exception(s) discuss in the thread. - -### 6. Around Code Freeze (~Week 13) +### 5. Around Code Freeze (~Week 13) Defer to the [code freeze section](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/release-team-lead#standards) in the release-team-lead handbook. #### Shortly before Code freeze @@ -170,7 +175,6 @@ Code Freeze begins, and it’s now the home stretch of the release. SIGs will ne - [ ] Monitor the enhancements GitHub project to get an idea of how many PRs are still outstanding leading up to Code Freeze - [ ] Monitor Testgrid and Prow to understand the stability of the release and PRs getting ready to merge. If Prow and Test grid are not in a good state consult folks from SIG Testing on delaying code freeze by a day if needed. - - If the release branch is not healthy, stable, and passing tests consistently, notify community through standard channels of need to rectify or code freeze will come early to force focus on stabilization. - [ ] Reminded the Branch Manager that branch CI jobs will be needed next week - [ ] Send out a reminder email to [kubernetes-dev](https://groups.google.com/a/kubernetes.io/g/dev) @@ -178,22 +182,34 @@ Code Freeze begins, and it’s now the home stretch of the release. SIGs will ne - As needed, assist the Release Signal Lead and Enhancements Lead removing PRs and enhancements from the milestone that aren't merged in time `/milestone clear` #### After Code Freeze -- [ ] Verified that the [`release-1.XX` branch](https://github.com/kubernetes/kubernetes/branches) has been automatically created at the start of Test Freeze +- [ ] Verified that the [`release-1.XX` branch](https://github.com/kubernetes/kubernetes/branches) has been created by the Branch Manager - [ ] Verified that the Branch Manager created the CI board on [Testgrid](https://testgrid.k8s.io/sig-release) for the release cycle (1.XX-blocking & 1.XX-informing) - [ ] Published the "Removals, Deprecations, and Major Changes blog" -### 7. Test Freeze up to Release Day (~Week 14) +### 6. Around Docs Freeze (~Week 12) + +#### Shortly before Docs Freeze +- [ ] Monitor the docs tab of the enhancements GitHub project to get an idea of how many PRs are still outstanding leading up to Docs Freeze. +- [ ] Make sure everyone knows Docs Freeze is coming the following week. (week 12) + +#### Week of Docs Freeze +- [ ] As needed, assist the Docs subteam lead with any last-minute escalations. + +#### After Docs Freeze +- [ ] Bring exceptions to the **#sig-release** Slack channel, start a thread for each, and ensure SIG representatives for the exception(s) discuss in the thread. + +### 7. Up to Release Day (~Week 14) - [ ] Verified together with the release-docs team that all KEPs with required documentation are ready for review - [ ] Completed release theme (slogan, logo and explanation text) and add it to the [release cycle documentation in k/sig-release/releases/release-1.XX](https://github.com/kubernetes/sig-release/tree/master/releases) - [ ] Decided with the Release team if burndown meetings are necessary or updates are done via Slack thread on Tuesdays and Thursdays -- [ ] Discussed Release Lead succession with the EA and sig-release leads -- [ ] Remind team lead to find successors for the upcoming cycle and discuss candidates with the EA +- [ ] Discussed Release Lead succession with the release team subproject owner and sig-release leads +- [ ] Remind team lead to find successors for the upcoming cycle and discuss candidates with the subproject owner - [ ] The task is now to ensure the release branch is ready to go. This means there are zero pending PRs, no failing 1.XX-blocking tests, no open issues in the milestone. This will continue until release day. - [ ] Final documentation PRs are reviewed and ready to be merged. Likely, this is not true and some are outstanding, so you need to help convince SIG doc writers to get these in with urgency. - [ ] Planned something for Release Day. Make the day as fun as you can for the team. Plan ahead for this and do something nice - [ ] Prepared [Release Team gifts](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/release-team-lead#release-theme-gifts) - [ ] The Communications Lead contacts CNCF to gauge media interest, schedule the CNCF Kubernetes release workshop, and publish the release blog post. Stay in the loop for that. If there is media interest in the release, an interview between the journalist will be organized by the CNCF. -- [ ] Check in with the docs lead and verify tasks that should happen before the release day are completed (ref [release-docs handbook](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/docs/Release-Timeline.md#release-week-week-12)) +- [ ] **Check in with the docs lead and verify tasks that should happen before the release day are completed (ref [release-docs handbook](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/docs/Release-Timeline.md#release-week-week-12))** - [ ] The Release Team Retro part 2 and part 3 is scheduled shortly after the "Release Halfway Point" and a host / facilitator is available - [ ] Remind the release team to add items to the retro meeting agenda @@ -238,9 +254,15 @@ Code Freeze begins, and it’s now the home stretch of the release. SIGs will ne - `milestone-maintainers` - `release-team` - `release-team-leads` + - `release-team-XX` (where XX is the release role, e.g. `release-team-enhancements`, `release-team-docs`, etc) - [ ] Remove from Google Groups/GCP IAM membership [(`kubernetes/k8s.io`)](https://git.k8s.io/k8s.io/groups/groups.yaml) - `k8s-infra-release-viewers@` + - `release-comms@` - `release-managers@` + - `release-team@` + - `release-team-shadows@` + - `k8s-infra-staging-tg-exporter@` + - `release-team-enhancements@` - [ ] Manually remove from the following Google Groups: - [kubernetes-release-team](https://groups.google.com/a/kubernetes.io/g/release-team) (Add as Manager) - [kubernetes-sig-leads](https://groups.google.com/forum/#!forum/kubernetes-sig-leads) (Add as Member) diff --git a/release-team/role-handbooks/release-team-lead/README.md b/release-team/role-handbooks/release-team-lead/README.md index b3d657d23c7..14af35f0b78 100644 --- a/release-team/role-handbooks/release-team-lead/README.md +++ b/release-team/role-handbooks/release-team-lead/README.md @@ -81,6 +81,27 @@ Release Team selection should happen in accordance with the [Release Team select ### Lead Shadows Once you have selected your Lead Shadows, each Shadow should get assigned to support two teams. One should be a team they have previously led or have extensive experience in. The other will be a team they have had no exposure to prior. They will work closely with their subteams to provide timely support. This will make sure that they are well-rounded to step up to lead. +As the communication between Lead Shadows and Subteam Leads happens without the Release Team Lead, it is important for the Release Team Lead to check in with the Lead Shadows as well as the Subteam Leads to ensure that everything is running smoothly. + +Lead Shadows are also required to assist in various subteam tasks (as a secondary reviewer after the subteam review), including but not limited to: + +- Documentation: + - Review Release Notes PRs for clarity and completeness. + - Branch Sync PRs are created timely to prevent branch skew. + - Assisting the documentation subteam before the docs freeze. +- Communications: + - Reviewing at least mid cycle blog and the release blog. +- Enhancements: + - Assisting the enhancements subteam before PRR, Enhancements, and Code+Test Freeze. +- Release Signal: + - Sporadically monitoring the release signal dashboard and alerting the Release Team Lead of any issues. + +The Release Lead Shadows are also required to assist in the following Release Team Lead tasks, including but not limited to: +- Hosting the Release Team meetings (see [Release Team Meeting Host Playbook](#release-team-meeting-host-playbook) for more details) +- Suggesting KEPs for mid cycle blog and release blog to the Release Team Lead and the Communications Lead. +- Coordinating any freeze requests and starting a discussion in #sig-release Slack channel. + +The Release Team Lead should explicitly assign above-mentioned and additional tasks to Lead Shadows as needed. In the event that a subteam loses a shadow, we might ask the paired Lead Shadow to step in as a backup Shadow. @@ -90,8 +111,13 @@ In the event that a subteam loses a shadow, we might ask the paired Lead Shadow - kubernetes/sig-release - releases/release-x.y - README.md (release schedule) - - release-notes-draft.md (consumed by the automated release process) - release_team.md + - exceptions.yaml (list of exceptions granted during enhancements, code+test freeze) + - release-notes + - release-notes-draft.md (consumed by the automated release process) + - release-notes-draft.json (json used by krel to generate release notes) + - logos (folder for release logos) + - OWNERS (only for the current devel release) - Short links are handled with [http://bit.ly](http://bit.ly). Each release should have the following documents (replacing XYY with the release version number minus dots): - Retro doc: `http://bit.ly/k8sXYYretro` - Release Schedule overview: `http://bit.ly/k8sXYY-release-info`