...

When opening a PR to a named release branch, tag for review the Release Manager from the Build-Test-Release Working Group , which can be determine from for a review. You can find the release manager in the working group’s README. Although not required, getting an a first PR review from one of your team members will show the Release Manager that someone else’s eyes have already been on your PR, which makes their job easier.

...

• top-level repository, signified by the presence of a open-release/XXX.master named release branch; or a

• library repository, which is installed into the release by Pip pip or NPM npm and thus doesn’t have a named release branch.

...

1. Ensure the change is already merged to master and deployed.

2. Find the commit hash(es) of the fix you need from master. They might be the same as in the fix pull request you are copying from, or they may be different if the pull request was closed with a squash. The best thing to do is to update your master branch, and get the hashes shown in your local git log:
   $ git log

3. Check out the release branch:
   $ git checkout open-release/XXX.master
$ git pull

4. Make a new branch from the release:
   $ git switch -c <YOURNAME>/<BRANCHNAME>

5. Cherry-pick the commits onto your branch. Do this for all your commits:
   $ git cherry-pick -x <COMMITHASH> ...

6. Push your branch:
   $ git push -u origin HEAD

7. Make a pull request from your branch, using open-release/XXX.master as the base. In your pull request description, mention the original pull request on master that you are copying, if you can.

8. Tag people for review. The pull request will be handled and merged like any other.

...

Making a change that is special to the named release

Sometimes a change is needed that doesn’t correspond to a change on master.

Changing a top-level repository

...