PEP 101: Add Android (#4541)

Author: mhsmith

peps/pep-0101.rst

@@ -146,19 +146,17 @@ release.  The roles and their current experts are:
   In rare cases where the expert for Windows or Mac is MIA, you may add
   a message "(Platform) binaries will be provided shortly" and proceed.
 
-As much as possible, the release steps are automated and guided by the
-release script, which is available in a separate repository:
-`python/release-tools`_.
-
 We use the following conventions in the examples below.  Where a release
 number is given, it is of the form ``3.X.YaN``, e.g. 3.13.0a3 for Python 3.13.0
 alpha 3, where "a" == alpha, "b" == beta, "rc" == release candidate.
 
 Release tags are named ``v3.X.YaN``.  The branch name for minor release
 maintenance branches is ``3.X``.
 
-This helps by performing several automatic editing steps, and guides you
-to perform some manual editing steps.
+As much as possible, the release is automated and guided by the
+``run_release.py`` script, which is available in a separate repository:
+`python/release-tools`_. This helps by automating many of the following steps,
+and guides you to perform some manual steps.
 
 - Log into Discord and join the Python Core Devs server. Ask Thomas
   or Łukasz for an invite.
@@ -287,55 +285,34 @@ to perform some manual editing steps.
 - For **begin security-only mode** and **end-of-life** releases, review the
   two files and update the versions accordingly in all active branches.
 
-- Time to build the source tarball.  Use the release script to create
-  the source gzip and xz tarballs,
-  documentation tar and zip files, and GPG signature files::
-
-    .../release-tools/release.py --export 3.X.YaN
-
-  This can take a while for **final** releases, and it will leave all the
-  tarballs and signatures in a subdirectory called ``3.X.YaN/src``, and the
-  built docs in ``3.X.YaN/docs`` (for **final** releases).
-
-  Note that the script will sign your release with Sigstore. Use
-  your **@python.org** email address for this. See here for more information:
-  https://www.python.org/download/sigstore/.
+- Push your commits to the remote release branch in your GitHub fork::
 
-- Now you want to perform the very important step of checking the
-  tarball you just created, to make sure a completely clean,
-  virgin build passes the regression test.  Here are the best
-  steps to take::
+    # Do a dry run first.
+    git push --dry-run --tags origin
+    # Make sure you are pushing to your GitHub fork,
+    # *not* to the main python/cpython repo!
+    git push --tags origin
 
-    cd /tmp
-    tar xvf /path/to/your/release/clone/<version>//Python-3.2rc2.tgz
-    cd Python-3.2rc2
-    ls
-    # (Do things look reasonable?)
-    ls Lib
-    # (Are there stray .pyc files?)
-    ./configure
-    # (Loads of configure output)
-    make test
-    # (Do all the expected tests pass?)
+- In `python/release-tools`_, go to the `build-release
+  <https://github.com/python/release-tools/actions/workflows/build-release.yml>`__
+  workflow, select "Run workflow", and enter the details of the tag you just
+  created. This will perform the following steps:
 
-  If you're feeling lucky and have some time to kill, or if you are making
-  a release candidate or **final** release, run the full test suite::
+  - Create the source gzip and xz tarballs.
+  - Create the documentation tar and zip files.
+  - Check the source tarball to make sure a completely clean, virgin build
+    passes the regression test.
+  - Build and test the Android binaries (if Python 3.14 or later).
 
-    make buildbottest
+  The resulting artifacts will be attached to the summary page of the GitHub
+  workflow. Once the source tarball is available, download and unpack it to make
+  sure things look reasonable, there are no stray .pyc files, etc.
 
   If the tests pass, then you can feel good that the tarball is
   fine.  If some of the tests fail, or anything else about the
   freshly unpacked directory looks weird, you better stop now and
   figure out what the problem is.
 
-- Push your commits to the remote release branch in your GitHub fork::
-
-    # Do a dry run first.
-    git push --dry-run --tags origin
-    # Make sure you are pushing to your GitHub fork,
-    # *not* to the main python/cpython repo!
-    git push --tags origin
-
 - Notify the experts that they can start building binaries.
 
 .. warning::
@@ -374,8 +351,9 @@ to perform some manual editing steps.
 - The ME builds Mac installer packages and uploads them to
   downloads.nyc1.psf.io together with GPG signature files.
 
-- ``scp`` or ``rsync`` all the files built by ``release.py --export``
-  to your home directory on ``downloads.nyc1.psf.io``.
+- ``scp`` or ``rsync`` all the files built by the build-release workflow
+  to your home directory on ``downloads.nyc1.psf.io``, along with any
+  signatures, SBOMs, etc.
 
   While you're waiting for the files to finish uploading, you can continue
   on with the remaining tasks.  You can also ask folks on Discord
@@ -390,8 +368,8 @@ to perform some manual editing steps.
     creating it if necessary.  Make sure it is owned by group ``downloads``
     and group-writable.
 
-  - Move the release ``.tgz``, and ``.tar.xz`` files into place, as well as the
-    ``.asc`` GPG signature files.  The Win/Mac binaries are usually put there
+  - Take the files you uploaded to your home directory above, and move them
+    into the release directory. The Win/Mac binaries are usually put there
     by the experts themselves.
 
     Make sure they are world readable.  They should also be group