Merge branch 'main' into 694-woodruff-dpo

Author: warsaw

.github/CODEOWNERS

@@ -431,7 +431,7 @@ peps/pep-0557.rst  @ericvsmith
 peps/pep-0558.rst  @ncoghlan
 peps/pep-0559.rst  @warsaw
 peps/pep-0560.rst  @ilevkivskyi
-# peps/pep-0561.rst
+peps/pep-0561.rst  @emmatyping
 peps/pep-0562.rst  @ilevkivskyi
 peps/pep-0563.rst  @ambv
 peps/pep-0564.rst  @vstinner
@@ -636,7 +636,7 @@ peps/pep-0755.rst  @warsaw
 peps/pep-0756.rst  @vstinner
 peps/pep-0757.rst  @vstinner
 peps/pep-0758.rst  @pablogsal @brettcannon
-peps/pep-0759.rst  @warsaw
+peps/pep-0759.rst  @warsaw @emmatyping
 peps/pep-0760.rst  @pablogsal @brettcannon
 peps/pep-0761.rst  @sethmlarson @hugovk
 peps/pep-0762.rst  @pablogsal @ambv @lysnikolaou @emilyemorehouse
@@ -654,15 +654,15 @@ peps/pep-0773.rst  @zooba
 peps/pep-0774.rst  @savannahostrowski
 peps/pep-0775.rst  @encukou
 peps/pep-0776.rst  @hoodmane @ambv
-peps/pep-0777.rst  @warsaw
-peps/pep-0778.rst  @warsaw
+peps/pep-0777.rst  @warsaw @emmatyping
+peps/pep-0778.rst  @warsaw @emmatyping
 # ...
 peps/pep-0779.rst  @Yhg1s @colesbury @mpage
 peps/pep-0780.rst  @lysnikolaou
 peps/pep-0781.rst  @methane
 peps/pep-0782.rst  @vstinner
 peps/pep-0783.rst  @hoodmane @ambv
-peps/pep-0784.rst  @gpshead
+peps/pep-0784.rst  @gpshead @emmatyping
 peps/pep-0785.rst  @gpshead
 # ...
 peps/pep-0787.rst  @ncoghlan
@@ -677,6 +677,7 @@ peps/pep-0798.rst  @JelleZijlstra
 peps/pep-0799.rst  @pablogsal
 peps/pep-0800.rst  @JelleZijlstra
 peps/pep-0801.rst  @warsaw
+peps/pep-0802.rst  @AA-Turner
 # ...
 peps/pep-2026.rst  @hugovk
 # ...

README.rst

@@ -49,7 +49,7 @@ You can find it in the merge box at the bottom of the PR page:
 Render PEPs locally
 -------------------
 
-See the `build documentation <./docs/build.rst>`__ for full
+See the `build documentation <./peps/docs/build.rst>`__ for full
 instructions on how to render PEPs locally.
 In summary, run the following in a fresh, activated virtual environment:
 

peps/conf.py

@@ -73,6 +73,7 @@
     "py3.12": ("https://docs.python.org/3.12/", None),
     "py3.13": ("https://docs.python.org/3.13/", None),
     "py3.14": ("https://docs.python.org/3.14/", None),
+    "py3.15": ("https://docs.python.org/3.15/", None),
     "python": ("https://docs.python.org/3/", None),
     "trio": ("https://trio.readthedocs.io/en/latest/", None),
     "typing": ("https://typing.python.org/en/latest/", None),

peps/contents.rst

@@ -15,6 +15,7 @@ This is an internal Sphinx page; please go to the :doc:`PEP Index <pep-0000>`.
    :caption: PEP Table of Contents (needed for Sphinx):
 
    api/*
+   docs/*
    topic/*
    numerical
    pep-*

docs/build.rst peps/docs/build.rstdocs/build.rst renamed to peps/docs/build.rst

@@ -0,0 +1,14 @@
+..
+   We can't use :pep:`N` references in this document, as they use links relative
+   to the current file, which doesn't work in a subdirectory like this one.
+
+PEPs Internal Documentation
+===========================
+
+This is documentation for the internals of the PEPs website and PEP rendering
+system. To read the PEPs, see the :doc:`PEP Index <../pep-0000>`.
+
+------------------------------------------------------------------------------
+
+* :doc:`Building PEPs Locally <./build>`
+* :doc:`An Overview of the PEP Rendering System <./rendering_system>`

peps/docs/index.rst

@@ -35,7 +35,7 @@ The configuration:
 ----------------
 
 ``build.py`` manages the rendering process.
-Usage is covered in `Building PEPs Locally <./build.rst>`_.
+Usage is covered in :doc:`Building PEPs Locally <./build>`.
 
 
 3. Extension

docs/rendering_system.rst peps/docs/rendering_system.rstdocs/rendering_system.rst renamed to peps/docs/rendering_system.rst

@@ -574,10 +574,14 @@ Each PEP should have the following parts/sections:
     ready for consideration are complete and reduces people duplicating
     prior discussion.
 
-12. Footnotes -- A collection of footnotes cited in the PEP, and
+12. Acknowledgements -- Useful to thank and acknowledge people who have helped
+    develop, discuss, or draft the PEP, or for any other purpose. The section
+    can be used to recognise contributors to the work who are not co-authors.
+
+13. Footnotes -- A collection of footnotes cited in the PEP, and
     a place to list non-inline hyperlink targets.
 
-13. Copyright/license -- Each new PEP must be placed under a dual license of
+14. Copyright/license -- Each new PEP must be placed under a dual license of
     public domain and CC0-1.0-Universal_ (see this PEP for an example).
 
 

peps/pep-0001.rst

@@ -76,6 +76,12 @@ Open Issues
 [Any points that are still being decided/discussed.]
 
 
+Acknowledgements
+================
+
+[Thank anyone who has helped with the PEP.]
+
+
 Footnotes
 =========
 

peps/pep-0012/pep-NNNN.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