From 97526bb5acded52f7fe5d6c4e0c15d5469d286c7 Mon Sep 17 00:00:00 2001 From: Claire Laurence Date: Wed, 5 Jun 2019 13:53:49 -0400 Subject: [PATCH] updates to release lead handbook updates to release lead handbook --- .../release-team-lead/README.md | 21 +++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/release-team/role-handbooks/release-team-lead/README.md b/release-team/role-handbooks/release-team-lead/README.md index 63d556c5a9..8e1b8dc1fa 100644 --- a/release-team/role-handbooks/release-team-lead/README.md +++ b/release-team/role-handbooks/release-team-lead/README.md @@ -81,7 +81,13 @@ Release Team selection should happen in accordance with the [Release Team Select ## Release Milestone Activities: -### Week 1 +### Before Release Begins +- Attend previous release retro to capture feedback and encorporate it into next release cycle +- Plan release schedule and milestones. Gather feedback as needed +- Make sure you have your shadows confirmed +- Have a handover meeting with the outgoing lead to get credentials to SIG Release Zoom and any other needed permissions + +### Week 1 - Start the release cycle - Ensure you are joined to the following Google Groups: @@ -93,12 +99,11 @@ Release Team selection should happen in accordance with the [Release Team Select - Ensure the release team is fully filled, with members subscribed to the kubernetes-milestone-burndown@googlegroups.com group. - Ensure top-level OWNERS_ALIASES only includes personnel from four (4) releases, including the current one. - Create and finalize the release schedule, blocking test gates, and role assignments as a pull request in: kubernetes/sig-release/releases/release-x.y/README.md -- Ensure that relevant feedback from the prior retrospective is incorporated into the process - Send an update to kubernetes-dev and kubernetes-sig-leads mailing list to announce the start of the release cycle, including any notable changes in the release process, key dates, and links to important documents - Create the retrospective document and corresponding bit.ly link -- Begin meeting with SIGs to introduce yourself +- Begin meeting with SIGs to introduce yourself - Begin paying attention to [CI signal](https://git.k8s.io/sig-release/release-team/role-handbooks/ci-signal/README.md), as it may begin degrading soon after the prior release is cut and any slips must be caught and rectified promptly. -- Request review of this document by the release lead shadow. The shadow should also take all actions in this document around joining groups and requesting access permissions. +- Request review of this document by the release lead shadow(s). The shadow(s) should also take all actions in this document around joining groups and requesting access permissions. ### Week 2 @@ -157,6 +162,14 @@ Release Halfway Point - SIGs that have not completed release themes should be contacted again, with a focus on explaining why this matters to the community - Ping release team 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. +#### Code Freeze Day +Code Freeze will typically fall around Weeks 8 or 9 depending on the length or release cycle. As Code Freeze approaches here are some good practices +- Monitor the enhancements spreadsheet to get an idea of how many PRs are still outstanding leading up to Code Freeze +- Send a reminder email to k-dev +- Monitor [Testgrid](https://testgrid.k8s.io/) and [Prow](https://prow.k8s.io/) 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. +- LGTM / Approve and remove the hold on the PR for enabling code freeze. [Example from 1.15 here](https://github.com/kubernetes/test-infra/pull/12808) +- As needed assist the Bug Triage lead and Enhancements lead removing PRs and enhancements from the milestone that aren't merged in time + ### Week 8 - The code exception process is now in effect, meaning you will likely have to assemble decision makers on specific pending PRs to assess whether the risk of inclusion is acceptable or not. Remember this is not you making a decision, it’s you helping SIGs follow the process, and ensuring there’s consensus. In the event of a contentious PR, you should err on the side of risk aversion. In extreme cases, you can defer to the steering committee, but that is extremely unlikely.