# Release Manager Pain Points

These are my personal views of the pain points that occurred during the branch cutting/initial release phases of the Istio 1.16 minor release.

For reference, here is Istio 1.16's preparation issue https://github.com/istio/istio/issues/41015 which will be discussed.

## Branch cut announcements

Send an announcement on Discuss announcing the start of branch cut and to stop merging of PRs (adding, but are branch cut notifications needed and where?)

PRs don't stop being merged in this step which causes cases where pings happen because they see the new branch but there's not yet labels or ways to cherry pick to it.

## Branch protection

Set up branch protection. Modify prow/config.yaml in test-infra to add release manages as owners for a branch.

The PR for this was eventually overridden by those with admin permissions in the repo, but the Testing On-Call group never responded to multiple pings and DMs on Slack which left this PR waiting several days for merging and leaving the release branch unprotected.

## Set up prow on release branches

(Automation/Not very automated step=3) (doesn't work locally, appears to need credential to add a tag to an existing build-tools image)(new step because this might need to be done separately) Set up prow on release branches go run generate.go branch 1.16 (Note: Needed to run postsubmit in next step) (Contact Googler or ping in #test-and-release slack channel for help).

This step caused the most pain during the branch cutting process. The only Googler that responded to requests for assistance during the branch cutting phase was John Howard, who was not familiar with this step. It took a full day of work with Eric to come up with the manual steps to complete this step. I have documented them on the issue to hopefully reduce the future work needed, but it is still a very long step and may be missing some additional automation (ie, the need to manually update the testgrid/config.yaml) due to lack of tooling or documentation.

## Cherry picks during branch cut

As briefly mentioned previously, during the branch cut phases merges are still occuring with various methods to cherry pick to the new release branch. If these are done prior to completion of "Automation step=4", the bot will assign the workgroups as PR reviewers for cherry picking, and it becomes confusing as to who needs to review PRs to merge to the new cherry picked branch.

## PR Approvals

Each step requires merging of various PRs across all the repos, and most of the time you cannot move on until they are merged and in many cases the post submits are done. The PR approval from various workgroups can be slow which holds up the branch cutting process.

## Timing

The Branch Cutting is scheduled to take a single day, however, given the timings it takes to get PRs approved and merged I don't feel this is a valid expectation. While generally not a big deal, this has caused pushing release dates for both 1.15 and 1.16. It might be best to schedule this process to take 2-3 days if a Googler is involved, and potentially a 4th if not.

## Long Running Tests

This is a pain point for every new release. There's a single point of contact to complete these, who seems like a really busy person. It can take between several days to a week to get a response on Slack. Ideally, these tests should be runnable by each release manager.