Merge branch 'main' into sboms-for-python-packages

Author: hugovk

.github/CODEOWNERS

@@ -625,6 +625,7 @@ peps/pep-0744.rst  @brandtbucher @savannahostrowski
 peps/pep-0745.rst  @hugovk
 peps/pep-0746.rst  @JelleZijlstra
 peps/pep-0747.rst  @JelleZijlstra
+peps/pep-0748.rst  @ncoghlan
 # ...
 peps/pep-0749.rst  @JelleZijlstra
 peps/pep-0750.rst  @gvanrossum @lysnikolaou
@@ -641,6 +642,10 @@ peps/pep-0760.rst  @pablogsal @brettcannon
 peps/pep-0761.rst  @sethmlarson @hugovk
 peps/pep-0762.rst  @pablogsal @ambv @lysnikolaou @emilyemorehouse
 peps/pep-0763.rst  @dstufft
+peps/pep-0765.rst  @iritkatriel @ncoghlan
+peps/pep-0766.rst  @warsaw
+peps/pep-0767.rst  @carljm
+peps/pep-0768.rst  @pablogsal
 peps/pep-0770.rst  @sethmlarson @brettcannon
 # ...
 peps/pep-0777.rst  @warsaw

.github/workflows/render.yml

@@ -23,7 +23,7 @@ jobs:
       matrix:
         python-version:
         - "3.x"
-        - "3.13-dev"
+        - "3.14-dev"
 
     steps:
       - name: Checkout

.github/workflows/test.yml

@@ -62,7 +62,8 @@ jobs:
           uvx --with tox-uv tox -e py -- -v --cov-report term
 
       - name: Upload coverage
-        uses: codecov/codecov-action@v4
+        uses: codecov/codecov-action@v5
         with:
           flags: ${{ matrix.os }}
           name: ${{ matrix.os }} Python ${{ matrix.python-version }}
+          token: ${{ secrets.CODECOV_ORG_TOKEN }}

.pre-commit-config.yaml

@@ -93,6 +93,7 @@ repos:
     hooks:
       - id: codespell
         name: "Check for common misspellings in text files"
+        require_serial: true
         stages: [manual]
 
   # Local checks for PEP headers and more

.readthedocs.yaml

@@ -5,7 +5,7 @@
 version: 2
 
 build:
-  os: ubuntu-22.04
+  os: ubuntu-lts-latest
   tools:
     python: "3"
 
@@ -17,6 +17,7 @@ build:
 
 sphinx:
   builder: dirhtml
+  configuration: peps/conf.py
 
 search:
   ignore: ['*']

Makefile

@@ -40,6 +40,7 @@ htmllive: _ensure-sphinx-autobuild html
 .PHONY: dirhtml
 dirhtml: BUILDER = dirhtml
 dirhtml: html
+	mv $(BUILDDIR)/404/index.html $(BUILDDIR)/404.html
 
 ## linkcheck      to check validity of links within PEP sources
 .PHONY: linkcheck

peps/conf.py

@@ -19,6 +19,7 @@
 
 # Add any Sphinx extension module names here, as strings.
 extensions = [
+    "notfound.extension",
     "pep_sphinx_extensions",
     "sphinx.ext.extlinks",
     "sphinx.ext.intersphinx",
@@ -85,6 +86,10 @@
     "pypi": ("https://pypi.org/project/%s/", "%s"),
 }
 
+# sphinx-notfound-page
+# https://sphinx-notfound-page.readthedocs.io/en/latest/faq.html#does-this-extension-work-with-github-pages
+notfound_urls_prefix = None
+
 # -- Options for HTML output -------------------------------------------------
 
 _PSE_PATH = _ROOT / "pep_sphinx_extensions"

peps/pep-0012/pep-NNNN.rst

@@ -1,8 +1,8 @@
 PEP: <REQUIRED: pep number>
 Title: <REQUIRED: pep title>
-Author: <REQUIRED: list of authors' real names and optionally, email addrs>
-Sponsor: <real name of sponsor>
-PEP-Delegate: <PEP delegate's real name>
+Author: <REQUIRED: list of authors' names and optionally, email addrs>
+Sponsor: <name of sponsor>
+PEP-Delegate: <PEP delegate's name>
 Discussions-To: <REQUIRED: URL of current canonical discussion thread>
 Status: <REQUIRED: Draft | Active | Accepted | Provisional | Deferred | Rejected | Withdrawn | Final | Superseded>
 Type: <REQUIRED: Standards Track | Informational | Process>

peps/pep-0013.rst

@@ -20,15 +20,15 @@ to exercise as rarely as possible.
 Current steering council
 ========================
 
-The 2024 term steering council consists of:
+The 2025 term steering council consists of:
 
 * Barry Warsaw
+* Donghee Na
 * Emily Morehouse
 * Gregory P. Smith
 * Pablo Galindo Salgado
-* Thomas Wouters
 
-Per the results of the vote tracked in :pep:`8105`.
+Per the results of the vote tracked in :pep:`8106`.
 
 The core team consists of those listed in the private
 https://github.com/python/voters/ repository which is publicly
@@ -105,9 +105,11 @@ A council election consists of two phases:
   must be nominated by a core team member. Self-nominations are
   allowed.
 
-* Phase 2: Each core team member can vote for zero or more of the
-  candidates. Voting is performed anonymously. Candidates are ranked
-  by the total number of votes they receive. If a tie occurs, it may
+* Phase 2: Each core team member can assign zero to five stars to each
+  candidate. Voting is performed anonymously. The outcome of the vote
+  is determined using the `STAR voting system <https://www.starvoting.org/>`__,
+  modified to use the `Multi-winner Bloc STAR <https://www.starvoting.org/multi_winner>`__)
+  approach. If a tie occurs, it may
   be resolved by mutual agreement among the candidates, or else the
   winner will be chosen at random.
 
@@ -190,7 +192,7 @@ council member, or the entire council, via a vote of no confidence.
 
 A no-confidence vote is triggered when a core team member calls for
 one publicly on an appropriate project communication channel, and
-another core team member seconds the proposal.
+another core team member seconds the proposal within one week.
 
 The vote lasts for two weeks. Core team members vote for or against.
 If at least two thirds of voters express a lack of confidence, then
@@ -270,6 +272,10 @@ It is granted by receiving at least two-thirds positive votes in a
 core team vote that is open for one week and is not vetoed by the
 steering council.
 
+.. note:: The devguide has a `suggested template
+   <https://devguide.python.org/core-developers/become-core-developer/#poll-template>`__
+   to use for such votes.
+
 Core team members are always looking for promising contributors,
 teaching them how the project is managed, and submitting their names
 to the core team's vote when they're ready.
@@ -301,6 +307,10 @@ Changing this document
 Changes to this document require at least a two-thirds majority of
 votes cast in a core team vote which should be open for two weeks.
 
+No vote is required to update note blocks and the "Current steering
+council" and "History of council elections" sections with current
+information.
+
 
 History
 =======
@@ -337,12 +347,17 @@ History of council elections
 * December 2021: :pep:`8103`
 * December 2022: :pep:`8104`
 * December 2023: :pep:`8105`
+* December 2024: :pep:`8106`
 
 
 History of amendments
 ---------------------
 
-2019-04-17: Added the vote length for core devs and changes to this document.
+* 2019-04-17: Added the vote length for core devs and changes to this document.
+* `2024-12-10 <https://discuss.python.org/t/64971>`__:
+  Adopted Multi-winner Bloc STAR voting for council elections.
+* `2024-12-10 <https://discuss.python.org/t/72293/4>`__:
+  Added a one-week deadline for seconding a vote of no confidence.
 
 
 

peps/pep-0101.rst

@@ -33,10 +33,13 @@ Here's a hopefully-complete list.
 
 * A GPG key.
 
-  Python releases are digitally signed with GPG; you'll need a key,
-  which hopefully will be on the "web of trust" with at least one of
+  Python releases before 3.14 are digitally signed with GPG; for these you'll
+  need a key, which hopefully will be on the "web of trust" with at least one of
   the other release managers.
 
+  .. note:: GPG instructions in this PEP can be ignored for Python 3.14 and
+            later. See :pep:`761` for details.
+
 * A bunch of software:
 
   * A checkout of the `python/release-tools`_ repo.
@@ -263,20 +266,6 @@ to perform some manual editing steps.
 - Make sure all changes have been committed.  (``release.py --bump``
   doesn't check in its changes for you.)
 
-- Check the years on the copyright notice.  If the last release
-  was some time last year, add the current year to the copyright
-  notice in several places:
-
-  - ``README``
-  - ``LICENSE`` (make sure to change on ``main`` and the branch)
-  - ``Python/getcopyright.c``
-  - ``Doc/copyright.rst``
-  - ``Doc/license.rst``
-  - ``PC/python_ver_rc.h`` sets up the DLL version resource for Windows
-    (displayed when you right-click on the DLL and select
-    Properties).  This isn't a C include file, it's a Windows
-    "resource file" include file.
-
 - For a **final** major release, edit the first paragraph of
   ``Doc/whatsnew/3.X.rst`` to include the actual release date; e.g. "Python
   2.5 was released on August 1, 2003."  There's no need to edit this for
@@ -610,7 +599,7 @@ the main repo.
   release branch (3.X-1) and use them as a template.
   https://github.com/python/cpython/settings/branches
 
-  Also, add a ``needs backport to 3.X`` label to the GitHub repo.
+  Also, add ``3.x`` and ``needs backport to 3.X`` labels to the GitHub repo.
   https://github.com/python/cpython/labels
 
 - You can now re-enable enforcement of branch settings against administrators
@@ -637,7 +626,7 @@ permissions.
   Python release "page", editing as you go.
 
   You can use `Markdown <https://daringfireball.net/projects/markdown/syntax>`_ or
-  `reStructured Text <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_
+  `reStructured Text <https://docutils.sourceforge.io/docs/user/rst/quickref.html>`_
   to describe your release.  The former is less verbose, while the latter has nifty
   integration for things like referencing PEPs.
 
@@ -742,28 +731,20 @@ permissions.
 
   * python-list@python.org
   * python-announce@python.org
-  * python-dev@python.org
 
 - Also post the announcement to the
-  `Python Insider blog <http://blog.python.org>`_.
+  `Python Insider blog <https://blog.python.org>`_.
   To add a new entry, go to
-  `your Blogger home page, here <https://www.blogger.com/home>`_.
+  `your Blogger home page <https://www.blogger.com/home>`_.
 
-- Update any release PEPs (e.g. 719) with the release dates.
+- Update `release PEPs <https://peps.python.org/topic/release/>`__
+  (e.g. 719) with the release dates.
 
 - Update the labels on https://github.com/python/cpython/issues:
 
   - Flip all the `deferred-blocker`_ issues back to `release-blocker`_
     for the next release.
 
-  - Add version ``3.X+1`` as when version ``3.X`` enters alpha.
-
-  - Change non-doc feature requests to version ``3.X+1`` when version ``3.X``
-    enters beta.
-
-  - Update issues from versions that your release makes
-    unsupported to the next supported version.
-
   - Review open issues, as this might find lurking showstopper bugs,
     besides reminding people to fix the easy ones they forgot about.
 
@@ -788,7 +769,7 @@ permissions.
     or Zach Ware).
 
   - Ensure the various GitHub bots are updated, as needed, for the
-    new branch, in particular, make sure backporting to the new
+    new branch. In particular, make sure backporting to the new
     branch works (contact the `core-workflow team
     <https://github.com/python/core-workflow/issues>`__).
 
@@ -801,7 +782,7 @@ permissions.
     branches and that the release branch is properly protected (no direct
     pushes, etc).
 
-  - Verify that the `on-line docs <https://docs.python.org/>`__ are building
+  - Verify that the `online docs <https://docs.python.org/>`__ are building
     properly (this may take up to 24 hours for a complete build on the website).
 
 
@@ -869,12 +850,16 @@ else does them.  Some of those tasks include:
 
 - Retire the release from the `issue tracker`_. Tasks include:
 
+  * update issues from this version to the next supported version
+
   * remove version label from list of versions
 
   * remove the ``needs backport to`` label for the retired version
 
   * review and dispose of open issues marked for this branch
 
+- Run a final build of the online docs to add the end-of-life banner
+
 - Announce the branch retirement in the usual places:
 
   * `discuss.python.org`_