Further document how to handle cherry-picks for final or rc2+ releases

pep-0101.txt

@@ -211,11 +211,14 @@ to perform some manual editing steps.
   tagging the release, and you will use it to share with the other experts
   for making the binaries.
 
-  For a **final** or **release candidate 2+** release, create a release
+  For a **final** or **release candidate 2+** release, if you are going
+  to cherry-pick a subset of changes for the next rc or final from all those
+  merged since the last rc, you should create a release
   engineering branch starting from the most recent release candidate tag,
   i.e. ``v3.8.0rc1``. You will then cherry-pick changes from the standard
   release branch as necessary into the release engineering branch and
-  then proceed as usual.
+  then proceed as usual.  If you are going to take all of the changes
+  since the previous rc, you can proceed as normal.
 
 - Notify all committers by sending email to python-committers@python.org.
 
@@ -557,6 +560,11 @@ the main repo.
 
     $ git checkout -b X.Y
 
+  Do any steps needed to setup the new release branch, including:
+
+        * In README.rst, change all references from ``master`` to
+          the new branch, in particular, GitHub repo URLs.
+
 - For *all* releases, do the guided post-release steps with the
   release script.::
 
@@ -591,7 +599,7 @@ the main repo.
         $ git checkout master
         $ .../release-tools/release.py --bump 3.9.0a0
 
-    - Edit all version references in the README
+    - Edit all version references in README.rst
 
     - Move any historical "what's new" entries from ``Misc/NEWS`` to
       ``Misc/HISTORY``.