PEP 9999: Creation of a CPython mirror

.github/CODEOWNERS

@@ -679,6 +679,7 @@ peps/pep-0800.rst  @JelleZijlstra
 peps/pep-0801.rst  @warsaw
 peps/pep-0802.rst  @AA-Turner
 peps/pep-0803.rst  @encukou
+peps/pep-0807.rst  @ezio-melotti
 # ...
 peps/pep-2026.rst  @hugovk
 # ...

peps/pep-0807.rst

@@ -0,0 +1,127 @@
+PEP: 807
+Title: Creation of a CPython mirror
+Author: Stan Ulbrych <stanulbrych@gmail.com>
+Sponsor: Ezio Melotti <ezio.melotti@gmail.com>
+Discussions-To: https://discuss.python.org/t/103671
+Status: Draft
+Type: Process
+Created: 10-Sep-2025
+Post-History: `10-Sep-2025 <https://discuss.python.org/t/103671>`__
+
+
+Abstract
+========
+
+This PEP proposes the creation of an official read-only mirror of the
+`CPython Git repository <https://github.com/python/cpython>`_,
+currently hosted on GitHub (since :pep:`512`), on an additional hosting
+platform to improve resilience.
+
+
+Motivation
+==========
+
+The authors believe that mirroring the repository on an alternative
+platform will limit
+`vendor lock-in <https://en.wikipedia.org/wiki/Vendor_lock-in>`_  and improve
+the security, resilience, and accessibility of CPython without impacting the
+current development workflow.
+Currently, the up-to-date CPython source code is officially available only
+on GitHub, following the retirement of `hg.python.org <https://hg.python.org/>`_.
+The idea of a mirror was originally noted in :pep:`512#the-fate-of-hg-python-org`.
+
+.. note::
+
+    The standard clone of a repository does not pull all information, see
+    the `Git documentation <https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---mirror>`_
+    for more information.
+
+Many open source projects provide mirrors, for example:
+`GNOME <https://github.com/GNOME>`_, `KDE <https://github.com/KDE?>`_,
+`Git <https://github.com/git/git>`_, `GCC <https://github.com/gcc-mirror/gcc>`_,
+`Linux <https://gitlab.com/linux-kernel/linux>`_, `curl <https://codeberg.org/curl/curl-mirror>`_,
+`FreeBSD <https://gitlab.com/FreeBSD/freebsd-src>`_, and `OpenBSD <https://github.com/openbsd/src>`_.
+
+Relying on a single storage provider carries the risk that, if the provider
+goes down, all data stored on the platform could be lost.
+This is similar to maintaining backups of personal data (photos, documents, etc.).
+
+In the event of a temporary outage, local development can still continue as
+one can pull the most recent state of the repository from the mirror.
+In the event of a permanent outage, having a mirror with the
+``python`` namespace would allow for a smoother migration to a new
+contribution platform as many things would already be set up, and
+a copy of the up-to-date source would be available.
+
+Some contributors prefer using open-source platforms to develop open source projects.
+Since `GitHub <github.com>`_ is not open source, a mirror would allow us to
+address this concern. Mirrors improve accessibility for contributors in regions
+where GitHub may be blocked [#ghcens]_ or slow.
+
+
+Rationale
+=========
+
+The mirror is **not** intended to replace the host for contributions
+(issues, pull requests, CI), but to provide an additional
+read-only distribution channel for the Git data (commits, branches, tags etc.)
+because having multiple contribution platforms would introduce excessive
+complexity and asynchrony.
+
+Mirrors require little maintenance and should not have a financial impact on
+the PSF, since many hosting providers offer free plans which are sufficient for
+a mirror.
+
+
+Specification
+=============
+
+The repository will be mirrored using Git's
+`--mirror <https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---mirror>`__
+option, either using a platform's built-in integration [#gldoc]_ or a script.
+The repository should be in the platform's equivalent of the GitHub
+`python organization <https://github.com/python/>`_.
+
+To avoid confusion, all contribution-related tabs (Issues, Pull Requests,
+Discussions, etc.) will be disabled, and the fact that the repository is a
+mirror will be clearly noted in the description.
+
+
+Security Implications
+=====================
+
+This PEP increases the security workload, as two platforms must be secured.
+Because the mirror is read-only, some risks of compromise are alleviated,
+but not all.
+
+Access to the repository should follow the
+`principle of least privilege <https://en.wikipedia.org/wiki/Principle_of_least_privilege>`_.
+
+
+Backwards Compatibility
+=======================
+
+This PEP has no effect on existing contributor workflows.
+
+
+Open Questions
+==============
+
+What platform should be used? The platform should be free, so as not to have a
+financial impact on the PSF. There are several options, for example
+`GitLab <https://gitlab.com/>`_ and `Codeberg <https://codeberg.org/>`_.
+
+
+Footnotes
+=========
+
+.. [#ghcens] `Wikipedia: Censorship of GitHub <https://en.wikipedia.org/wiki/Censorship_of_GitHub>`_
+
+.. [#gldoc] `GitLab: Repository mirroring documentation <https://docs.gitlab.com/user/project/repository/mirror/>`_
+
+
+Copyright
+=========
+
+This document is placed in the public domain or under the
+CC0-1.0-Universal license, whichever is more permissive.