CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 512 – Migrating from hg.python.org to GitHub | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0512/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 512 – Migrating from hg.python.org to GitHub | peps.python.org'> <meta property="og:description" content="This PEP outlines the steps required to migrate Python’s development process from Mercurial 3 as hosted at hg.python.org 1 to Git 4 on GitHub 2. Meeting the minimum goals of this PEP should allow for the development process of Python to be as productive..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0512/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="This PEP outlines the steps required to migrate Python’s development process from Mercurial 3 as hosted at hg.python.org 1 to Git 4 on GitHub 2. Meeting the minimum goals of this PEP should allow for the development process of Python to be as productive..."> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 512</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> <span class="visually-hidden">Toggle light / dark / auto colour theme</span> </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 512 – Migrating from hg.python.org to GitHub</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Brett Cannon <brett at python.org></dd> <dt class="field-even">Discussions-To<span class="colon">:</span></dt> <dd class="field-even"><a class="reference external" href="https://mail.python.org/archives/list/core-workflow@python.org/">Core-Workflow list</a></dd> <dt class="field-odd">Status<span class="colon">:</span></dt> <dd class="field-odd"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd> <dt class="field-even">Type<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Normative PEP describing or proposing a change to a Python community process, workflow or governance">Process</abbr></dd> <dt class="field-odd">Created<span class="colon">:</span></dt> <dd class="field-odd">17-Jan-2015</dd> <dt class="field-even">Post-History<span class="colon">:</span></dt> <dd class="field-even">17-Jan-2016, 19-Jan-2016, 23-Jan-2016</dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#repositories-to-migrate">Repositories to Migrate</a></li> <li><a class="reference internal" href="#migration-plan">Migration Plan</a><ul> <li><a class="reference internal" href="#requirements-for-code-only-repositories">Requirements for Code-Only Repositories</a><ul> <li><a class="reference internal" href="#create-a-python-core-team">Create a ‘Python core’ team</a></li> <li><a class="reference internal" href="#define-commands-to-move-a-mercurial-repository-to-git">Define commands to move a Mercurial repository to Git</a></li> <li><a class="reference internal" href="#cla-enforcement">CLA enforcement</a><ul> <li><a class="reference internal" href="#adding-github-username-support-to-bugs-python-org">Adding GitHub username support to bugs.python.org</a></li> <li><a class="reference internal" href="#a-bot-to-enforce-cla-signing">A bot to enforce CLA signing</a></li> </ul> </li> <li><a class="reference internal" href="#make-old-repository-read-only">Make old repository read-only</a></li> </ul> </li> <li><a class="reference internal" href="#requirements-for-web-related-repositories">Requirements for Web-Related Repositories</a></li> <li><a class="reference internal" href="#requirements-for-the-cpython-repository">Requirements for the cpython Repository</a><ul> <li><a class="reference internal" href="#document-steps-to-commit-a-pull-request">Document steps to commit a pull request</a></li> <li><a class="reference internal" href="#linking-pull-requests-to-issues">Linking pull requests to issues</a><ul> <li><a class="reference internal" href="#linking-a-pull-request-to-an-issue">Linking a pull request to an issue</a></li> <li><a class="reference internal" href="#notify-the-issue-if-a-commit-is-made">Notify the issue if a commit is made</a></li> </ul> </li> <li><a class="reference internal" href="#update-the-linking-service-for-mapping-commit-ids-to-urls">Update the linking service for mapping commit IDs to URLs</a></li> <li><a class="reference internal" href="#deprecate-sys-mercurial">Deprecate sys._mercurial</a></li> <li><a class="reference internal" href="#update-the-devguide">Update the devguide</a></li> <li><a class="reference internal" href="#update-pep-101">Update PEP 101</a></li> </ul> </li> <li><a class="reference internal" href="#optional-planned-features">Optional, Planned Features</a><ul> <li><a class="reference internal" href="#handling-misc-news">Handling Misc/NEWS</a></li> <li><a class="reference internal" href="#handling-misc-acks">Handling Misc/ACKS</a></li> <li><a class="reference internal" href="#create-https-git-python-org">Create <code class="docutils literal notranslate"><span class="pre">https://git.python.org</span></code></a></li> <li><a class="reference internal" href="#backup-of-pull-request-data">Backup of pull request data</a></li> <li><a class="reference internal" href="#bot-to-generate-cherry-pick-pull-requests">Bot to generate cherry-pick pull requests</a></li> <li><a class="reference internal" href="#pull-request-commit-queue">Pull request commit queue</a></li> <li><a class="reference internal" href="#a-ci-service">A CI service</a></li> <li><a class="reference internal" href="#test-coverage-report">Test coverage report</a></li> <li><a class="reference internal" href="#notifying-issues-of-pull-request-comments">Notifying issues of pull request comments</a></li> <li><a class="reference internal" href="#allow-bugs-python-org-to-use-github-as-a-login-provider">Allow bugs.python.org to use GitHub as a login provider</a></li> <li><a class="reference internal" href="#web-hooks-for-re-generating-web-content">Web hooks for re-generating web content</a></li> <li><a class="reference internal" href="#link-web-content-back-to-files-that-it-is-generated-from">Link web content back to files that it is generated from</a></li> <li><a class="reference internal" href="#splitting-out-parts-of-the-documentation-into-their-own-repositories">Splitting out parts of the documentation into their own repositories</a></li> <li><a class="reference internal" href="#backup-of-git-repositories">Backup of Git repositories</a></li> <li><a class="reference internal" href="#identify-potential-new-core-developers">Identify potential new core developers</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#status">Status</a><ul> <li><a class="reference internal" href="#cpython-repo">cpython repo </a></li> </ul> </li> <li><a class="reference internal" href="#open-issues">Open Issues</a><ul> <li><a class="reference internal" href="#the-fate-of-hg-python-org">The fate of hg.python.org</a></li> <li><a class="reference internal" href="#git-cli-commands-for-committing-a-pull-request-to-cpython">Git CLI commands for committing a pull request to cpython</a></li> <li><a class="reference internal" href="#naming-the-bots">Naming the bots</a></li> </ul> </li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#separate-python-2-and-python-3-repositories">Separate Python 2 and Python 3 repositories</a></li> <li><a class="reference internal" href="#commit-multi-release-changes-in-bugfix-branch-first">Commit multi-release changes in bugfix branch first</a></li> <li><a class="reference internal" href="#deriving-misc-news-from-the-commit-logs">Deriving <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> from the commit logs</a></li> <li><a class="reference internal" href="#deriving-misc-news-from-bugs-python-org">Deriving <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> from bugs.python.org</a></li> </ul> </li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <div class="admonition note"> <p class="admonition-title">Note</p> <p>CPython’s development process moved to <a class="reference external" href="https://github.com/python/cpython">https://github.com/python/cpython</a> on 2017-02-10.</p> </div> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <p>This PEP outlines the steps required to migrate Python’s development process from Mercurial <a class="footnote-reference brackets" href="#hg" id="id1">[3]</a> as hosted at hg.python.org <a class="footnote-reference brackets" href="#h-p-o" id="id2">[1]</a> to Git <a class="footnote-reference brackets" href="#git" id="id3">[4]</a> on GitHub <a class="footnote-reference brackets" href="#github" id="id4">[2]</a>. Meeting the minimum goals of this PEP should allow for the development process of Python to be as productive as it currently is, and meeting its extended goals should improve the development process from its status quo.</p> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> <p>In 2014, it became obvious that Python’s custom development process was becoming a hindrance. As an example, for an external contributor to submit a fix for a bug that eventually was committed, the basic steps were:</p> <ol class="arabic simple"> <li>Open an issue for the bug at bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id5">[5]</a>.</li> <li>Checkout out the CPython source code from hg.python.org <a class="footnote-reference brackets" href="#h-p-o" id="id6">[1]</a>.</li> <li>Make the fix.</li> <li>Upload a patch.</li> <li>Have a core developer review the patch using our fork of the Rietveld code review tool <a class="footnote-reference brackets" href="#rietveld" id="id7">[6]</a>.</li> <li>Download the patch to make sure it still applies cleanly.</li> <li>Run the test suite manually.</li> <li>Update the <code class="docutils literal notranslate"><span class="pre">NEWS</span></code>, <code class="docutils literal notranslate"><span class="pre">ACKS</span></code>, and “What’s New” document as necessary</li> <li>Pull changes to avoid a merge race.</li> <li>Commit the change manually.</li> <li>If the change was for a bugfix release, merge into the in-development branch.</li> <li>Run the test suite manually again.</li> <li>Commit the merge.</li> <li>Push the changes.</li> </ol> <p>This is a very heavy, manual process for core developers. Even in the simple case, you could only possibly skip the code review step, as you would still need to build the documentation. This led to patches languishing on the issue tracker due to core developers not being able to work through the backlog fast enough to keep up with submissions. In turn, that led to a side-effect issue of discouraging outside contribution due to frustration from lack of attention, which is a dangerous problem for an open source project with no corporate backing as it runs counter to having a viable future for the project. While allowing patches to be uploaded to bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id8">[5]</a> is potentially simple for an external contributor, it is as slow and burdensome as it gets for a core developer to work with.</p> <p>Hence the decision was made in late 2014 that a move to a new development process was needed. A request for PEPs proposing new workflows was made, in the end leading to two: <a class="pep reference internal" href="../pep-0481/" title="PEP 481 – Migrate CPython to Git, Github, and Phabricator">PEP 481</a> and <a class="pep reference internal" href="../pep-0507/" title="PEP 507 – Migrate CPython to Git and GitLab">PEP 507</a> proposing GitHub <a class="footnote-reference brackets" href="#github" id="id9">[2]</a> and GitLab <a class="footnote-reference brackets" href="#gitlab" id="id10">[7]</a>, respectively.</p> <p>The year 2015 was spent off-and-on working on those proposals and trying to tease out details of what made them different from each other on the core-workflow mailing list <a class="footnote-reference brackets" href="#core-workflow" id="id11">[8]</a>. PyCon US 2015 also showed that the community was a bit frustrated with our process due to both cognitive overhead for new contributors and how long it was taking for core developers to look at a patch (see the end of Guido van Rossum’s keynote at PyCon US 2015 <a class="footnote-reference brackets" href="#guido-keynote" id="id12">[9]</a> as an example of the frustration).</p> <p>On January 1, 2016, the decision was made by Brett Cannon to move the development process to GitHub. The key reasons for choosing GitHub were <a class="footnote-reference brackets" href="#reasons" id="id13">[10]</a>:</p> <ul class="simple"> <li>Maintaining custom infrastructure has been a burden on volunteers (e.g., an unmaintained, custom fork of Rietveld <a class="footnote-reference brackets" href="#rietveld" id="id14">[6]</a> is currently being used).</li> <li>The custom workflow is very time-consuming for core developers (not enough automated tooling built to help support it).</li> <li>The custom workflow is a hindrance to external contributors (acts as a barrier of entry due to time required to ramp up on development process unique to CPython itself).</li> <li>There is no feature differentiating GitLab from GitHub beyond GitLab being open source.</li> <li>Familiarity with GitHub is far higher among core developers and external contributors than with GitLab.</li> <li>Our BDFL prefers GitHub (who would be the first person to tell you that his opinion shouldn’t matter, but the person making the decision felt it was important that the BDFL feel comfortable with the workflow of his own programming language to encourage his continued participation).</li> </ul> <p>There’s even already an unofficial logo to represent the migration to GitHub <a class="footnote-reference brackets" href="#pythocat" id="id15">[22]</a>.</p> <p>The overarching goal of this migration is to improve the development process to the extent that a core developer can go from external contribution submission through all the steps leading to committing said contribution from within a browser on a tablet with WiFi using <em>some</em> development process (this does not inherently mean GitHub’s default workflow). The final solution will also allow an external contributor to contribute even if they chose not to use GitHub (although there is not guarantee in feature parity).</p> </section> <section id="repositories-to-migrate"> <h2><a class="toc-backref" href="#repositories-to-migrate" role="doc-backlink">Repositories to Migrate</a></h2> <p>While hg.python.org <a class="footnote-reference brackets" href="#h-p-o" id="id16">[1]</a> hosts many repositories, there are only five key repositories that need to move:</p> <ol class="arabic simple"> <li>devinabox <a class="footnote-reference brackets" href="#devinabox-repo" id="id17">[12]</a> (done)</li> <li>benchmarks <a class="footnote-reference brackets" href="#benchmarks-repo" id="id18">[11]</a> (skipped)</li> <li>peps <a class="footnote-reference brackets" href="#peps-repo" id="id19">[13]</a> (done)</li> <li>devguide <a class="footnote-reference brackets" href="#devguide-repo" id="id20">[14]</a> (done)</li> <li>cpython <a class="footnote-reference brackets" href="#id75" id="id21">[15]</a></li> </ol> <p>The devinabox repository is code-only. The peps and devguide repositories involve the generation of webpages. And the cpython repository has special requirements for integration with bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id22">[5]</a>.</p> </section> <section id="migration-plan"> <h2><a class="toc-backref" href="#migration-plan" role="doc-backlink">Migration Plan</a></h2> <p>The migration plan is separated into sections based on what is required to migrate the repositories listed in the <a class="reference internal" href="#repositories-to-migrate">Repositories to Migrate</a> section. Completion of requirements outlined in each section should unblock the migration of the related repositories. The sections are expected to be completed in order, but not necessarily the requirements within a section.</p> <section id="requirements-for-code-only-repositories"> <h3><a class="toc-backref" href="#requirements-for-code-only-repositories" role="doc-backlink">Requirements for Code-Only Repositories</a></h3> <p>Completion of the requirements in this section will allow the devinabox repository to move to GitHub.</p> <section id="create-a-python-core-team"> <h4><a class="toc-backref" href="#create-a-python-core-team" role="doc-backlink">Create a ‘Python core’ team</a></h4> <p>To manage permissions, a ‘Python core’ team will be created as part of the python organization <a class="footnote-reference brackets" href="#github-python-org" id="id23">[16]</a>. Any repository that is moved will have the ‘Python core’ team added to it with write permissions <a class="footnote-reference brackets" href="#github-org-perms" id="id24">[17]</a>. Anyone who previously had rights to manage SSH keys on hg.python.org will become a team maintainer for the ‘Python core’ team.</p> </section> <section id="define-commands-to-move-a-mercurial-repository-to-git"> <h4><a class="toc-backref" href="#define-commands-to-move-a-mercurial-repository-to-git" role="doc-backlink">Define commands to move a Mercurial repository to Git</a></h4> <p>Since moving to GitHub also entails moving to Git <a class="footnote-reference brackets" href="#git" id="id25">[4]</a>, we must decide what tools and commands we will run to translate a Mercurial repository to Git. The tools developed specifically for this migration are hosted at <a class="reference external" href="https://github.com/orsenthil/cpython-hg-to-git">https://github.com/orsenthil/cpython-hg-to-git</a> .</p> </section> <section id="cla-enforcement"> <h4><a class="toc-backref" href="#cla-enforcement" role="doc-backlink">CLA enforcement</a></h4> <p>A key part of any open source project is making sure that its source code can be properly licensed. This requires making sure all people making contributions have signed a contributor license agreement (CLA) <a class="footnote-reference brackets" href="#cla" id="id26">[18]</a>. Up until now, enforcement of CLA signing of contributed code has been enforced by core developers checking whether someone had an <code class="docutils literal notranslate"><span class="pre">*</span></code> by their username on bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id27">[5]</a>. With this migration, the plan is to start off with automated checking and enforcement of contributors signing the CLA.</p> <section id="adding-github-username-support-to-bugs-python-org"> <h5><a class="toc-backref" href="#adding-github-username-support-to-bugs-python-org" role="doc-backlink">Adding GitHub username support to bugs.python.org</a></h5> <p>To keep tracking of CLA signing under the direct control of the PSF, tracking who has signed the PSF CLA will be continued by marking that fact as part of someone’s bugs.python.org user profile. What this means is that an association will be needed between a person’s bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id28">[5]</a> account and their GitHub account, which will be done through a new field in a user’s profile. This does implicitly require that contributors will need both a GitHub <a class="footnote-reference brackets" href="#github" id="id29">[2]</a> and bugs.python.org account in order to sign the CLA and contribute through GitHub.</p> <p>An API is provided to query bugs.python.org to see if a GitHub username corresponds to someone who has signed the CLA. Making a GET request to e.g. <a class="reference external" href="http://bugs.python.org/user?@template=clacheck&github_names=brettcannon,notanuser">http://bugs.python.org/user?@template=clacheck&github_names=brettcannon,notanuser</a> returns a JSON dictionary with the keys of the usernames requested and a <code class="docutils literal notranslate"><span class="pre">true</span></code> value if they have signed the CLA, <code class="docutils literal notranslate"><span class="pre">false</span></code> if they have not, and <code class="docutils literal notranslate"><span class="pre">null</span></code> if no corresponding GitHub username was found.</p> </section> <section id="a-bot-to-enforce-cla-signing"> <h5><a class="toc-backref" href="#a-bot-to-enforce-cla-signing" role="doc-backlink">A bot to enforce CLA signing</a></h5> <p>With an association between someone’s GitHub account and their bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id30">[5]</a> account, which has the data as to whether someone has signed the CLA, a bot can monitor pull requests on GitHub and denote whether the contributor has signed the CLA.</p> <p>If the user has signed the CLA, the bot will add a positive label to the issue to denote the pull request has no CLA issues (e.g., a green label stating, “CLA signed”). If the contributor has not signed a CLA, a negative label will be added to the pull request will be blocked using GitHub’s status API (e.g., a red label stating, “CLA not signed”). If a contributor lacks a bugs.python.org account, that will lead to the negative label being used as well. Using a label for both positive and negative cases provides a fallback signal if the bot happens to fail, preventing potential false-positives or false-negatives. It also allows for an easy way to trigger the bot again by simply removing a CLA-related label (this is in contrast to using a GitHub status check <a class="footnote-reference brackets" href="#gh-status-check" id="id31">[40]</a> which is only triggered on code changes).</p> <p>As no pre-existing bot exists to meet our needs, it will be hosted on Heroku <a class="footnote-reference brackets" href="#heroku" id="id32">[39]</a> and written to target Python 3.5 to act as a showcase for asynchronous programming. The code for the bot is hosted in the Knights Who Say Ni project <a class="footnote-reference brackets" href="#ni" id="id33">[41]</a>.</p> </section> </section> <section id="make-old-repository-read-only"> <h4><a class="toc-backref" href="#make-old-repository-read-only" role="doc-backlink">Make old repository read-only</a></h4> <p>Updating <code class="docutils literal notranslate"><span class="pre">.hg/hgrc</span></code> in the now-old Mercurial repository in the <code class="docutils literal notranslate"><span class="pre">[hooks]</span></code> section with:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">pretxnchangegroup</span><span class="o">.</span><span class="n">reject</span> <span class="o">=</span> <span class="n">echo</span> <span class="s2">" * This repo has been migrated to github.com/python/peps and does not accept new commits in Mercurial!"</span> <span class="mi">2</span><span class="o">>&</span><span class="mi">1</span><span class="p">;</span> <span class="n">exit</span> <span class="mi">1</span> </pre></div> </div> <p>will make the repository read-only.</p> </section> </section> <section id="requirements-for-web-related-repositories"> <h3><a class="toc-backref" href="#requirements-for-web-related-repositories" role="doc-backlink">Requirements for Web-Related Repositories</a></h3> <p>Due to their use for generating webpages, the devguide <a class="footnote-reference brackets" href="#devguide-repo" id="id34">[14]</a> and peps <a class="footnote-reference brackets" href="#peps-repo" id="id35">[13]</a> repositories need their respective processes updated to pull from their new Git repositories.</p> </section> <section id="requirements-for-the-cpython-repository"> <h3><a class="toc-backref" href="#requirements-for-the-cpython-repository" role="doc-backlink">Requirements for the cpython Repository</a></h3> <p>Obviously the most active and important repository currently hosted at hg.python.org <a class="footnote-reference brackets" href="#h-p-o" id="id36">[1]</a> is the cpython repository <a class="footnote-reference brackets" href="#id75" id="id37">[15]</a>. Because of its importance and high-frequency use, it requires more tooling before being moved to GitHub compared to the other repositories mentioned in this PEP.</p> <section id="document-steps-to-commit-a-pull-request"> <h4><a class="toc-backref" href="#document-steps-to-commit-a-pull-request" role="doc-backlink">Document steps to commit a pull request</a></h4> <p>During the process of choosing a new development workflow, it was decided that a linear history is desired. People preferred having a single commit representing a single change instead of having a set of unrelated commits lead to a merge commit that represented a single change. This means that the convenient “Merge” button in GitHub pull requests will be set to only do <em>squash</em> commits and not merge commits.</p> <p>A second set of recommended commands will also be written for committing a contribution from a patch file uploaded to bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id38">[5]</a>. This will obviously help keep the linear history, but it will need to be made to have attribution to the patch author.</p> <p>The exact sequence of commands that will be given as guidelines to core developers is an open issue: <a class="reference internal" href="#git-cli-commands-for-committing-a-pull-request-to-cpython">Git CLI commands for committing a pull request to cpython</a>.</p> </section> <section id="linking-pull-requests-to-issues"> <h4><a class="toc-backref" href="#linking-pull-requests-to-issues" role="doc-backlink">Linking pull requests to issues</a></h4> <p>Historically, external contributions were attached to an issue on bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id39">[5]</a> thanks to the fact that all external contributions were uploaded as a file. For changes committed by a core developer who committed a change directly, the specifying of an issue number in the commit message of the format <code class="docutils literal notranslate"><span class="pre">Issue</span> <span class="pre">#</span></code> at the start of the message led to a comment being posted to the issue linking to the commit.</p> <section id="linking-a-pull-request-to-an-issue"> <h5><a class="toc-backref" href="#linking-a-pull-request-to-an-issue" role="doc-backlink">Linking a pull request to an issue</a></h5> <p>An association between a pull request and an issue is needed to track when a fix has been proposed. The association needs to be many-to-one as there can take multiple pull requests to solve a single issue (technically it should be a many-to-many association for when a single fix solves multiple issues, but this is fairly rare and issues can be merged into one using the <code class="docutils literal notranslate"><span class="pre">Superseder</span></code> field on the issue tracker).</p> <p>The association between a pull request and an issue will be done based on detecting an issue number. If the issue is specified in either the title or in the body of a message on a pull request then a connection will be made on bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id40">[5]</a>. Some visible notification – e.g. label or message – will be made to the pull request to notify that the association was successfully made.</p> </section> <section id="notify-the-issue-if-a-commit-is-made"> <h5><a class="toc-backref" href="#notify-the-issue-if-a-commit-is-made" role="doc-backlink">Notify the issue if a commit is made</a></h5> <p>Once a commit is made, the corresponding issue should be updated to reflect this fact. This should work regardless of whether the commit came from a pull request or a direct commit.</p> </section> </section> <section id="update-the-linking-service-for-mapping-commit-ids-to-urls"> <h4><a class="toc-backref" href="#update-the-linking-service-for-mapping-commit-ids-to-urls" role="doc-backlink">Update the linking service for mapping commit IDs to URLs</a></h4> <p>Currently you can use <a class="reference external" href="https://hg.python.org/lookup/">https://hg.python.org/lookup/</a> with a revision ID from either the Subversion or Mercurial copies of the cpython repo <a class="footnote-reference brackets" href="#id75" id="id41">[15]</a> to get redirected to the URL for that revision in the Mercurial repository. The URL rewriter will need to be updated to redirect to the Git repository and to support the new revision IDs created for the Git repository.</p> <p>The most likely design is to statically know all the Mercurial changeset numbers once the migration has occurred. The lookup code will then be updated to accept hashes from 7 to 40 hexadecimal digits. Any hexadecimal of length 12 or 40 will be compared against the Mercurial changeset numbers. If the number doesn’t match or is of some other length between 7 and 40 then it will be assumed to be a Git hash.</p> <p>The <a class="reference external" href="https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.py#l76">bugs.python.org commit number rewriter</a> will also need to be updated to accept hashes as short as 7 digits as Git will match on hashes that short or longer.</p> </section> <section id="deprecate-sys-mercurial"> <h4><a class="toc-backref" href="#deprecate-sys-mercurial" role="doc-backlink">Deprecate sys._mercurial</a></h4> <p>Once Python is no longer kept in Mercurial, the <code class="docutils literal notranslate"><span class="pre">sys._mercurial</span></code> attribute will need to be changed to return <code class="docutils literal notranslate"><span class="pre">('CPython',</span> <span class="pre">'',</span> <span class="pre">'')</span></code>. An equivalent <code class="docutils literal notranslate"><span class="pre">sys._git</span></code> attribute will be added which fulfills the same use-cases.</p> </section> <section id="update-the-devguide"> <h4><a class="toc-backref" href="#update-the-devguide" role="doc-backlink">Update the devguide</a></h4> <p>The devguide will need to be updated with details of the new workflow. Mostly likely work will take place in a separate branch until the migration actually occurs.</p> </section> <section id="update-pep-101"> <h4><a class="toc-backref" href="#update-pep-101" role="doc-backlink">Update PEP 101</a></h4> <p>The release process will need to be updated as necessary.</p> </section> </section> <section id="optional-planned-features"> <h3><a class="toc-backref" href="#optional-planned-features" role="doc-backlink">Optional, Planned Features</a></h3> <p>Once the cpython repository <a class="footnote-reference brackets" href="#id75" id="id42">[15]</a> is migrated, all repositories will have been moved to GitHub <a class="footnote-reference brackets" href="#github" id="id43">[2]</a> and the development process should be on equal footing as before the move. But a key reason for this migration is to improve the development process, making it better than it has ever been. This section outlines some plans on how to improve things.</p> <p>It should be mentioned that overall feature planning for bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id44">[5]</a> – which includes plans independent of this migration – are tracked on their own wiki page <a class="footnote-reference brackets" href="#tracker-plans" id="id45">[23]</a>.</p> <section id="handling-misc-news"> <h4><a class="toc-backref" href="#handling-misc-news" role="doc-backlink">Handling Misc/NEWS</a></h4> <p>Traditionally the <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> file <a class="footnote-reference brackets" href="#news-file" id="id46">[19]</a> has been problematic for changes which spanned Python releases. Oftentimes there will be merge conflicts when committing a change between e.g., 3.5 and 3.6 only in the <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> file. It’s so common, in fact, that the example instructions in the devguide explicitly mention how to resolve conflicts in the <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> file <a class="footnote-reference brackets" href="#devguide-merge-across-branches" id="id47">[21]</a>. As part of our tool modernization, working with the <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> file will be simplified.</p> <p>The planned approach is to use an individual file per news entry, containing the text for the entry. In this scenario, each feature release would have its own directory for news entries and a separate file would be created in that directory that was either named after the issue it closed or a timestamp value (which prevents collisions). Merges across branches would have no issue as the news entry file would still be uniquely named and in the directory of the latest version that contained the fix. A script would collect all news entry files no matter what directory they reside in and create an appropriate news file (the release directory can be ignored as the mere fact that the file exists is enough to represent that the entry belongs to the release). Classification can either be done by keyword in the new entry file itself or by using subdirectories representing each news entry classification in each release directory (or classification of news entries could be dropped since critical information is captured by the “What’s New” documents which are organized). The benefit of this approach is that it keeps the changes with the code that was actually changed. It also ties the message to being part of the commit which introduced the change. For a commit made through the CLI, a script could be provided to help generate the file. In a bot-driven scenario, the merge bot could have a way to specify a specific news entry and create the file as part of its flattened commit (while most likely also supporting using the first line of the commit message if no specific news entry was specified). If a web-based workflow is used then a status check could be used to verify that a new entry file is in the pull request to act as a reminder that the file is missing. Code for this approach has been written previously for the Mercurial workflow at <a class="reference external" href="http://bugs.python.org/issue18967">http://bugs.python.org/issue18967</a>. There is also tools from the community like <a class="reference external" href="https://pypi.python.org/pypi/towncrier">https://pypi.python.org/pypi/towncrier</a>, <a class="reference external" href="https://github.com/twisted/newsbuilder">https://github.com/twisted/newsbuilder</a>, and <a class="reference external" href="http://docs.openstack.org/developer/reno/">http://docs.openstack.org/developer/reno/</a>.</p> <p>Discussions at the Sep 2016 Python core-dev sprints led to this decision compared to the rejected approaches outlined in the <code class="docutils literal notranslate"><span class="pre">Rejected</span> <span class="pre">Ideas</span></code> section of this PEP. The separate files approach seems to have the right balance of flexibility and potential tooling out of the various options while solving the motivating problem.</p> <p>Work for this is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/6">https://github.com/python/core-workflow/issues/6</a>.</p> </section> <section id="handling-misc-acks"> <h4><a class="toc-backref" href="#handling-misc-acks" role="doc-backlink">Handling Misc/ACKS</a></h4> <p>Traditionally the <code class="docutils literal notranslate"><span class="pre">Misc/ACKS</span></code> file <a class="footnote-reference brackets" href="#acks-file" id="id48">[20]</a> has been managed by hand. But thanks to Git supporting an <code class="docutils literal notranslate"><span class="pre">author</span></code> value as well as a <code class="docutils literal notranslate"><span class="pre">committer</span></code> value per commit, authorship of a commit can be part of the history of the code itself.</p> <p>As such, manual management of <code class="docutils literal notranslate"><span class="pre">Misc/ACKS</span></code> will become optional. A script will be written that will collect all author and committer names and merge them into <code class="docutils literal notranslate"><span class="pre">Misc/ACKS</span></code> with all of the names listed prior to the move to Git. Running this script will become part of the release process.</p> <p>The script should also generate a list of all people who contributed since the last execution. This will allow having a list of those who contributed to a specific release so they can be explicitly thanked.</p> <p>Work for this is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/7">https://github.com/python/core-workflow/issues/7</a>.</p> </section> <section id="create-https-git-python-org"> <h4><a class="toc-backref" href="#create-https-git-python-org" role="doc-backlink">Create <code class="docutils literal notranslate"><span class="pre">https://git.python.org</span></code></a></h4> <p>Just as hg.python.org <a class="footnote-reference brackets" href="#h-p-o" id="id49">[1]</a> currently points to the Mercurial repository for Python, git.python.org should do the equivalent for the Git repository.</p> </section> <section id="backup-of-pull-request-data"> <h4><a class="toc-backref" href="#backup-of-pull-request-data" role="doc-backlink">Backup of pull request data</a></h4> <p>Since GitHub <a class="footnote-reference brackets" href="#github" id="id50">[2]</a> is going to be used for code hosting and code review, those two things need to be backed up. In the case of code hosting, the backup is implicit as all non-shallow Git <a class="footnote-reference brackets" href="#git" id="id51">[4]</a> clones contain the full history of the repository, hence there will be many backups of the repository.</p> <p>The code review history does not have the same implicit backup mechanism as the repository itself. That means a daily backup of code review history should be done so that it is not lost in case of any issues with GitHub. It also helps guarantee that a migration from GitHub to some other code review system is feasible were GitHub to disappear overnight.</p> </section> <section id="bot-to-generate-cherry-pick-pull-requests"> <h4><a class="toc-backref" href="#bot-to-generate-cherry-pick-pull-requests" role="doc-backlink">Bot to generate cherry-pick pull requests</a></h4> <p>Since the decision has been made to work with cherry-picks instead of forward merging of branches, it would be convenient to have a bot that would generate pull requests based on cherry-picking for any pull requests that affect multiple branches. The most likely design is a bot that monitors merged pull requests with key labels applied that delineate what branches the pull request should be cherry-picked into. The bot would then generate cherry-pick pull requests for each label and remove the labels as the pull requests are created (this allows for easy detection when automatic cherry-picking failed).</p> <p>Work for this is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/8">https://github.com/python/core-workflow/issues/8</a>.</p> </section> <section id="pull-request-commit-queue"> <h4><a class="toc-backref" href="#pull-request-commit-queue" role="doc-backlink">Pull request commit queue</a></h4> <p>This would linearly apply accepted pull requests and verify that the commits did not interfere with each other by running the test suite and backing out commits if the test run failed. To help facilitate the speed of testing, all patches committed since the last test run can be applied at once under a single test run as the optimistic assumption is that the patches will work in tandem. Some mechanism to re-run the tests in case of test flakiness will be needed, whether it is from removing a “test failed” label, web interface for core developers to trigger another testing event, etc.</p> <p>Inspiration or basis of the bot could be taken from pre-existing bots such as Homu <a class="footnote-reference brackets" href="#homu" id="id52">[31]</a> or Zuul <a class="footnote-reference brackets" href="#zuul" id="id53">[32]</a>.</p> <p>The name given to this bot in order to give it commands is an open issue: <a class="reference internal" href="#naming-the-bots">Naming the bots</a>.</p> </section> <section id="a-ci-service"> <h4><a class="toc-backref" href="#a-ci-service" role="doc-backlink">A CI service</a></h4> <p>There are various CI services that provide free support for open source projects hosted on GitHub <a class="footnote-reference brackets" href="#github" id="id54">[2]</a>. After experimenting with a couple CI services, the decision was made to go with Travis <a class="footnote-reference brackets" href="#travis" id="id55">[33]</a>.</p> <p>The current CI service for Python is Pypatcher <a class="footnote-reference brackets" href="#pypatcher" id="id56">[38]</a>. A request can be made in IRC to try a patch from bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id57">[5]</a>. The results can be viewed at <a class="reference external" href="https://ci.centos.org/job/cPython-build-patch/">https://ci.centos.org/job/cPython-build-patch/</a> .</p> <p>Work for this is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/1">https://github.com/python/core-workflow/issues/1</a>.</p> </section> <section id="test-coverage-report"> <h4><a class="toc-backref" href="#test-coverage-report" role="doc-backlink">Test coverage report</a></h4> <p>Getting an up-to-date test coverage report for Python’s standard library would be extremely beneficial as generating such a report can take quite a while to produce.</p> <p>There are a couple pre-existing services that provide free test coverage for open source projects. In the end, Codecov <a class="footnote-reference brackets" href="#codecov" id="id58">[37]</a> was chosen as the best option.</p> <p>Work for this is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/2">https://github.com/python/core-workflow/issues/2</a>.</p> </section> <section id="notifying-issues-of-pull-request-comments"> <h4><a class="toc-backref" href="#notifying-issues-of-pull-request-comments" role="doc-backlink">Notifying issues of pull request comments</a></h4> <p>The current development process does not include notifying an issue on bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id59">[5]</a> when a review comment is left on Rietveld <a class="footnote-reference brackets" href="#rietveld" id="id60">[6]</a>. It would be nice to fix this so that people can subscribe only to comments at bugs.python.org and not GitHub <a class="footnote-reference brackets" href="#github" id="id61">[2]</a> and yet still know when something occurs on GitHub in terms of review comments on relevant pull requests. Current thinking is to post a comment to bugs.python.org to the relevant issue when at least one review comment has been made over a certain period of time (e.g., 15 or 30 minutes, although with GitHub now supporting <a class="reference external" href="https://help.github.com/articles/reviewing-changes-in-pull-requests/">reviews</a> the time aspect may be unnecessary). This keeps the email volume down for those that receive both GitHub and bugs.python.org email notifications while still making sure that those only following bugs.python.org know when there might be a review comment to address.</p> </section> <section id="allow-bugs-python-org-to-use-github-as-a-login-provider"> <h4><a class="toc-backref" href="#allow-bugs-python-org-to-use-github-as-a-login-provider" role="doc-backlink">Allow bugs.python.org to use GitHub as a login provider</a></h4> <p>As of right now, bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id62">[5]</a> allows people to log in using Google, Launchpad, or OpenID credentials. It would be good to expand this to GitHub credentials.</p> </section> <section id="web-hooks-for-re-generating-web-content"> <h4><a class="toc-backref" href="#web-hooks-for-re-generating-web-content" role="doc-backlink">Web hooks for re-generating web content</a></h4> <p>The content at <a class="reference external" href="https://docs.python.org/">https://docs.python.org/</a>, <a class="reference external" href="https://docs.python.org/devguide">https://docs.python.org/devguide</a>, and <a class="reference external" href="https://www.python.org/dev/peps/">https://www.python.org/dev/peps/</a> are all derived from files kept in one of the repositories to be moved as part of this migration. As such, it would be nice to set up appropriate webhooks to trigger rebuilding the appropriate web content when the files they are based on change instead of having to wait for, e.g., a cronjob to trigger.</p> <p>This can partially be solved if the documentation is a Sphinx project as then the site can have an unofficial mirror on <a class="reference external" href="https://readthedocs.org/">Read the Docs</a>, e.g. <a class="reference external" href="http://cpython-devguide.readthedocs.io/">http://cpython-devguide.readthedocs.io/</a>.</p> <p>Work for this is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/9">https://github.com/python/core-workflow/issues/9</a>.</p> </section> <section id="link-web-content-back-to-files-that-it-is-generated-from"> <h4><a class="toc-backref" href="#link-web-content-back-to-files-that-it-is-generated-from" role="doc-backlink">Link web content back to files that it is generated from</a></h4> <p>It would be helpful for people who find issues with any of the documentation that is generated from a file to have a link on each page which points back to the file on GitHub <a class="footnote-reference brackets" href="#github" id="id63">[2]</a> that stores the content of the page. That would allow for quick pull requests to fix simple things such as spelling mistakes.</p> <p>Work for this is being tracked at <a class="reference external" href="http://bugs.python.org/issue28929">http://bugs.python.org/issue28929</a>.</p> </section> <section id="splitting-out-parts-of-the-documentation-into-their-own-repositories"> <h4><a class="toc-backref" href="#splitting-out-parts-of-the-documentation-into-their-own-repositories" role="doc-backlink">Splitting out parts of the documentation into their own repositories</a></h4> <p>While certain parts of the documentation at <a class="reference external" href="https://docs.python.org">https://docs.python.org</a> change with the code, other parts are fairly static and are not tightly bound to the CPython code itself. The following sections of the documentation fit this category of slow-changing, loosely-coupled:</p> <ul class="simple"> <li><a class="reference external" href="https://docs.python.org/3/tutorial/index.html">Tutorial</a></li> <li><a class="reference external" href="https://docs.python.org/3/using/index.html">Python Setup and Usage</a></li> <li><a class="reference external" href="https://docs.python.org/3/howto/index.html">HOWTOs</a></li> <li><a class="reference external" href="https://docs.python.org/3/installing/index.html">Installing Python Modules</a></li> <li><a class="reference external" href="https://docs.python.org/3/distributing/index.html">Distributing Python Modules</a></li> <li><a class="reference external" href="https://docs.python.org/3/extending/index.html">Extending and Embedding</a></li> <li><a class="reference external" href="https://docs.python.org/3/faq/index.html">FAQs</a></li> </ul> <p>These parts of the documentation could be broken out into their own repositories to simplify their maintenance and to expand who has commit rights to them to ease in their maintenance.</p> <p>It has also been suggested to split out the <a class="reference external" href="https://docs.python.org/3/whatsnew/index.html">What’s New</a> documents. That would require deciding whether a workflow could be developed where it would be difficult to forget to update What’s New (potentially through a label added to PRs, like “What’s New needed”).</p> </section> <section id="backup-of-git-repositories"> <h4><a class="toc-backref" href="#backup-of-git-repositories" role="doc-backlink">Backup of Git repositories</a></h4> <p>While not necessary, it would be good to have official backups of the various Git repositories for disaster protection. It will be up to the PSF infrastructure committee to decide if this is worthwhile or unnecessary.</p> </section> <section id="identify-potential-new-core-developers"> <h4><a class="toc-backref" href="#identify-potential-new-core-developers" role="doc-backlink">Identify potential new core developers</a></h4> <p>The Python development team has long-standing guidelines for selecting new core developers. The key part of the guidelines is that a person needs to have contributed multiple patches which have been accepted and are high enough quality and size to demonstrate an understanding of Python’s development process. A bot could be written which tracks patch acceptance rates and generates a report to help identify contributors who warrant consideration for becoming core developers. This work doesn’t even necessarily require GitHub integration as long as the committer field in all git commits is filled in properly.</p> <p>Work is being tracked at <a class="reference external" href="https://github.com/python/core-workflow/issues/10">https://github.com/python/core-workflow/issues/10</a>.</p> </section> </section> </section> <section id="status"> <h2><a class="toc-backref" href="#status" role="doc-backlink">Status</a></h2> <p>Requirements for migrating the devinabox <a class="footnote-reference brackets" href="#devinabox-repo" id="id64">[12]</a> repository:</p> <ul class="simple"> <li>Completed<ul> <li><a class="reference internal" href="#adding-github-username-support-to-bugs-python-org">Adding GitHub username support to bugs.python.org</a> (Maciej Szulik and Ezio Melotti)</li> <li><a class="reference internal" href="#a-bot-to-enforce-cla-signing">A bot to enforce CLA signing</a>: <a class="reference external" href="https://github.com/python/the-knights-who-say-ni">https://github.com/python/the-knights-who-say-ni</a> (Brett Cannon)</li> <li><a class="reference internal" href="#create-a-python-core-team">Create a ‘Python core’ team</a></li> <li><a class="reference internal" href="#define-commands-to-move-a-mercurial-repository-to-git">Define commands to move a Mercurial repository to Git</a>: <a class="reference external" href="https://github.com/orsenthil/cpython-hg-to-git">https://github.com/orsenthil/cpython-hg-to-git</a> (Senthil Kumaran)</li> </ul> </li> </ul> <p>Repositories whose build steps need updating:</p> <ul class="simple"> <li>Completed<ul> <li>peps <a class="footnote-reference brackets" href="#peps-repo" id="id65">[13]</a></li> <li>devguide <a class="footnote-reference brackets" href="#devguide-repo" id="id66">[14]</a></li> </ul> </li> </ul> <section id="cpython-repo"> <h3><a class="toc-backref" href="#cpython-repo" role="doc-backlink">cpython repo <a class="footnote-reference brackets" href="#id75" id="id67">[15]</a></a></h3> <p>Required:</p> <ul class="simple"> <li>Not started<ul> <li><a class="reference internal" href="#update-pep-101">Update PEP 101</a> (commitment from Ned Deily to do this; <strong>non-blocker</strong>)</li> </ul> </li> <li>In progress<ul> <li><a class="reference internal" href="#deprecate-sys-mercurial">Deprecate sys._mercurial</a> (<a class="reference external" href="http://bugs.python.org/issue27593">http://bugs.python.org/issue27593</a>; review committal from Ned Deily; <strong>non-blocker</strong>)</li> <li><a class="reference internal" href="#update-the-linking-service-for-mapping-commit-ids-to-urls">Update the linking service for mapping commit IDs to URLs</a> (code ready, needs deployment once the hg repository is made read-only; <a class="reference external" href="https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9">https://gist.github.com/brettcannon/f8d97c92b0df264cd4db008ffd32daf9</a>; <strong>post-migration</strong>)</li> </ul> </li> <li>Completed<ul> <li><a class="reference internal" href="#notify-the-issue-if-a-commit-is-made">Notify the issue if a commit is made</a> (<a class="reference external" href="http://psf.upfronthosting.co.za/roundup/meta/issue611">http://psf.upfronthosting.co.za/roundup/meta/issue611</a>)</li> <li>Track PR status in appropriate issue (<a class="reference external" href="http://psf.upfronthosting.co.za/roundup/meta/issue590">http://psf.upfronthosting.co.za/roundup/meta/issue590</a>)</li> <li><a class="reference internal" href="#update-the-devguide">Update the devguide</a>, including <a class="reference internal" href="#document-steps-to-commit-a-pull-request">Document steps to commit a pull request</a> (<a class="reference external" href="https://github.com/python/devguide/milestone/1">https://github.com/python/devguide/milestone/1</a>)</li> <li>Update commit hash detection on b.p.o to support 10- and 11-character hashes (<a class="reference external" href="http://psf.upfronthosting.co.za/roundup/meta/issue610">http://psf.upfronthosting.co.za/roundup/meta/issue610</a>)</li> <li><a class="reference internal" href="#linking-a-pull-request-to-an-issue">Linking a pull request to an issue</a> (<a class="reference external" href="http://psf.upfronthosting.co.za/roundup/meta/issue589">http://psf.upfronthosting.co.za/roundup/meta/issue589</a>)</li> <li>Email python-checkins for each commit (PR or direct) (<a class="reference external" href="https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/">https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/</a>)</li> <li>Message #python-dev for each commit (PR or direct) (<a class="reference external" href="https://github.com/python/cpython/settings/hooks/new?service=irc">https://github.com/python/cpython/settings/hooks/new?service=irc</a>)</li> <li>Get docs built from git (<a class="reference external" href="https://github.com/python/docsbuild-scripts/blob/main/build_docs.py">https://github.com/python/docsbuild-scripts/blob/main/build_docs.py</a> already updated; <a class="reference external" href="https://github.com/python/psf-salt/pull/91">https://github.com/python/psf-salt/pull/91</a> to switch)</li> <li>Migrate buildbots to be triggered and pull from GitHub</li> </ul> </li> </ul> <p>Optional features:</p> <ul class="simple"> <li>Not started<ul> <li>Check for whitespace abnormalities as part of CI</li> <li><a class="reference internal" href="#create-https-git-python-org">Create https://git.python.org</a></li> <li><a class="reference internal" href="#backup-of-pull-request-data">Backup of pull request data</a></li> <li><a class="reference internal" href="#handling-misc-acks">Handling Misc/ACKS</a></li> <li><a class="reference internal" href="#pull-request-commit-queue">Pull request commit queue</a></li> <li><a class="reference internal" href="#allow-bugs-python-org-to-use-github-as-a-login-provider">Allow bugs.python.org to use GitHub as a login provider</a></li> <li><a class="reference internal" href="#web-hooks-for-re-generating-web-content">Web hooks for re-generating web content</a></li> <li><a class="reference internal" href="#splitting-out-parts-of-the-documentation-into-their-own-repositories">Splitting out parts of the documentation into their own repositories</a></li> <li><a class="reference internal" href="#backup-of-git-repositories">Backup of Git repositories</a></li> </ul> </li> <li>In progress<ul> <li><a class="reference internal" href="#notifying-issues-of-pull-request-comments">Notifying issues of pull request comments</a> (<a class="reference external" href="http://psf.upfronthosting.co.za/roundup/meta/issue592">http://psf.upfronthosting.co.za/roundup/meta/issue592</a>)</li> <li>Convert b.p.o patches to GitHub PRs (<a class="reference external" href="http://psf.upfronthosting.co.za/roundup/meta/issue600">http://psf.upfronthosting.co.za/roundup/meta/issue600</a>)</li> </ul> </li> <li>Completed<ul> <li><a class="reference internal" href="#a-ci-service">A CI Service</a></li> <li><a class="reference internal" href="#test-coverage-report">Test coverage report</a></li> <li><a class="reference internal" href="#link-web-content-back-to-files-that-it-is-generated-from">Link web content back to files that it is generated from</a></li> <li><a class="reference internal" href="#handling-misc-news">Handling Misc/NEWS</a></li> <li><a class="reference internal" href="#bot-to-generate-cherry-pick-pull-requests">Bot to generate cherry-pick pull requests</a></li> <li>Write <code class="docutils literal notranslate"><span class="pre">.github/CONTRIBUTING.md</span></code> (to prevent PRs that are inappropriate from even showing up and pointing to the devguide)</li> </ul> </li> </ul> </section> </section> <section id="open-issues"> <h2><a class="toc-backref" href="#open-issues" role="doc-backlink">Open Issues</a></h2> <p>For this PEP, open issues are ones where a decision needs to be made to how to approach or solve a problem. Open issues do not entail coordination issues such as who is going to write a certain bit of code.</p> <section id="the-fate-of-hg-python-org"> <h3><a class="toc-backref" href="#the-fate-of-hg-python-org" role="doc-backlink">The fate of hg.python.org</a></h3> <p>With the code repositories moving over to Git <a class="footnote-reference brackets" href="#git" id="id68">[4]</a>, there is no technical need to keep hg.python.org <a class="footnote-reference brackets" href="#h-p-o" id="id69">[1]</a> running. Having said that, some in the community would like to have it stay functioning as a Mercurial <a class="footnote-reference brackets" href="#hg" id="id70">[3]</a> mirror of the Git repositories. Others have said that they still want a mirror, but one using Git.</p> <p>As maintaining hg.python.org is not necessary, it will be up to the PSF infrastructure committee to decide if they want to spend the time and resources to keep it running. They may also choose whether they want to host a Git mirror on PSF infrastructure.</p> <p>Depending on the decision reached, other ancillary repositories will either be forced to migration or they can choose to simply stay on hg.python.org.</p> </section> <section id="git-cli-commands-for-committing-a-pull-request-to-cpython"> <h3><a class="toc-backref" href="#git-cli-commands-for-committing-a-pull-request-to-cpython" role="doc-backlink">Git CLI commands for committing a pull request to cpython</a></h3> <p>Because Git <a class="footnote-reference brackets" href="#git" id="id71">[4]</a> may be a new version control system for core developers, the commands people are expected to run will need to be written down. These commands also need to keep a linear history while giving proper attribution to the pull request author.</p> <p>Another set of commands will also be necessary for when working with a patch file uploaded to bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id72">[5]</a>. Here the linear history will be kept implicitly, but it will need to make sure to keep/add attribution.</p> </section> <section id="naming-the-bots"> <h3><a class="toc-backref" href="#naming-the-bots" role="doc-backlink">Naming the bots</a></h3> <p>As naming things can lead to bikeshedding of epic proportions, Brett Cannon will choose the final name of the various bots (the name of the project for the bots themselves can be anything, this is purely for the name used in giving commands to the bot or the account name). The names must come from Monty Python, which is only fitting since Python is named after the comedy troupe.</p> </section> </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> <section id="separate-python-2-and-python-3-repositories"> <h3><a class="toc-backref" href="#separate-python-2-and-python-3-repositories" role="doc-backlink">Separate Python 2 and Python 3 repositories</a></h3> <p>It was discussed whether separate repositories for Python 2 and Python 3 were desired. The thinking was that this would shrink the overall repository size which benefits people with slow Internet connections or small bandwidth caps.</p> <p>In the end it was decided that it was easier logistically to simply keep all of CPython’s history in a single repository.</p> </section> <section id="commit-multi-release-changes-in-bugfix-branch-first"> <h3><a class="toc-backref" href="#commit-multi-release-changes-in-bugfix-branch-first" role="doc-backlink">Commit multi-release changes in bugfix branch first</a></h3> <p>As the current development process has changes committed in the oldest branch first and then merged up to the default branch, the question came up as to whether this workflow should be perpetuated. In the end it was decided that committing in the newest branch and then cherry-picking changes into older branches would work best as most people will instinctively work off the newest branch and it is a more common workflow when using Git <a class="footnote-reference brackets" href="#git" id="id73">[4]</a>.</p> <p>Cherry-picking is also more bot-friendly for an in-browser workflow. In the merge-up scenario, if you were to request a bot to do a merge and it failed, then you would have to make sure to immediately solve the merge conflicts if you still allowed the main commit, else you would need to postpone the entire commit until all merges could be handled. With a cherry-picking workflow, the main commit could proceed while postponing the merge-failing cherry-picks. This allows for possibly distributing the work of managing conflicting merges.</p> <p>Lastly, cherry-picking should help avoid merge races. Currently, when one is doing work that spans branches, it takes time to commit in the older branch, possibly push to another clone representing the <code class="docutils literal notranslate"><span class="pre">default</span></code> branch, merge the change, and then push upstream. Cherry-picking should decouple this so that you don’t have to rush your multi-branch changes as the cherry-pick can be done separately.</p> </section> <section id="deriving-misc-news-from-the-commit-logs"> <h3><a class="toc-backref" href="#deriving-misc-news-from-the-commit-logs" role="doc-backlink">Deriving <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> from the commit logs</a></h3> <p>As part of the discussion surrounding <a class="reference internal" href="#handling-misc-news">Handling Misc/NEWS</a>, the suggestion has come up of deriving the file from the commit logs itself. In this scenario, the first line of a commit message would be taken to represent the news entry for the change. Some heuristic to tie in whether a change warranted a news entry would be used, e.g., whether an issue number is listed.</p> <p>This idea has been rejected due to some core developers preferring to write a news entry separate from the commit message. The argument is the first line of a commit message compared to that of a news entry have different requirements in terms of brevity, what should be said, etc.</p> </section> <section id="deriving-misc-news-from-bugs-python-org"> <h3><a class="toc-backref" href="#deriving-misc-news-from-bugs-python-org" role="doc-backlink">Deriving <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> from bugs.python.org</a></h3> <p>A rejected solution to the <code class="docutils literal notranslate"><span class="pre">NEWS</span></code> file problem was to specify the entry on bugs.python.org <a class="footnote-reference brackets" href="#b-p-o" id="id74">[5]</a>. This would mean an issue that is marked as “resolved” could not be closed until a news entry is added in the “news” field in the issue tracker. The benefit of tying the news entry to the issue is it makes sure that all changes worthy of a news entry have an accompanying issue. It also makes classifying a news entry automatic thanks to the Component field of the issue. The Versions field of the issue also ties the news entry to which Python releases were affected. A script would be written to query bugs.python.org for relevant new entries for a release and to produce the output needed to be checked into the code repository. This approach is agnostic to whether a commit was done by CLI or bot. A drawback is that there’s a disconnect between the actual commit that made the change and the news entry by having them live in separate places (in this case, GitHub and bugs.python.org). This would mean making a commit would then require remembering to go back to bugs.python.org to add the news entry.</p> </section> </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="h-p-o" role="doc-footnote"> <dt class="label" id="h-p-o">[1]<em> (<a href='#id2'>1</a>, <a href='#id6'>2</a>, <a href='#id16'>3</a>, <a href='#id36'>4</a>, <a href='#id49'>5</a>, <a href='#id69'>6</a>) </em></dt> <dd><a class="reference external" href="https://hg.python.org">https://hg.python.org</a></aside> <aside class="footnote brackets" id="github" role="doc-footnote"> <dt class="label" id="github">[2]<em> (<a href='#id4'>1</a>, <a href='#id9'>2</a>, <a href='#id29'>3</a>, <a href='#id43'>4</a>, <a href='#id50'>5</a>, <a href='#id54'>6</a>, <a href='#id61'>7</a>, <a href='#id63'>8</a>) </em></dt> <dd>GitHub (<a class="reference external" href="https://github.com">https://github.com</a>)</aside> <aside class="footnote brackets" id="hg" role="doc-footnote"> <dt class="label" id="hg">[3]<em> (<a href='#id1'>1</a>, <a href='#id70'>2</a>) </em></dt> <dd>Mercurial (<a class="reference external" href="https://www.mercurial-scm.org/">https://www.mercurial-scm.org/</a>)</aside> <aside class="footnote brackets" id="git" role="doc-footnote"> <dt class="label" id="git">[4]<em> (<a href='#id3'>1</a>, <a href='#id25'>2</a>, <a href='#id51'>3</a>, <a href='#id68'>4</a>, <a href='#id71'>5</a>, <a href='#id73'>6</a>) </em></dt> <dd>Git (<a class="reference external" href="https://git-scm.com/">https://git-scm.com/</a>)</aside> <aside class="footnote brackets" id="b-p-o" role="doc-footnote"> <dt class="label" id="b-p-o">[5]<em> (<a href='#id5'>1</a>, <a href='#id8'>2</a>, <a href='#id22'>3</a>, <a href='#id27'>4</a>, <a href='#id28'>5</a>, <a href='#id30'>6</a>, <a href='#id38'>7</a>, <a href='#id39'>8</a>, <a href='#id40'>9</a>, <a href='#id44'>10</a>, <a href='#id57'>11</a>, <a href='#id59'>12</a>, <a href='#id62'>13</a>, <a href='#id72'>14</a>, <a href='#id74'>15</a>) </em></dt> <dd><a class="reference external" href="https://bugs.python.org">https://bugs.python.org</a></aside> <aside class="footnote brackets" id="rietveld" role="doc-footnote"> <dt class="label" id="rietveld">[6]<em> (<a href='#id7'>1</a>, <a href='#id14'>2</a>, <a href='#id60'>3</a>) </em></dt> <dd>Rietveld (<a class="reference external" href="https://github.com/rietveld-codereview/rietveld">https://github.com/rietveld-codereview/rietveld</a>)</aside> <aside class="footnote brackets" id="gitlab" role="doc-footnote"> <dt class="label" id="gitlab">[<a href="#id10">7</a>]</dt> <dd>GitLab (<a class="reference external" href="https://about.gitlab.com/">https://about.gitlab.com/</a>)</aside> <aside class="footnote brackets" id="core-workflow" role="doc-footnote"> <dt class="label" id="core-workflow">[<a href="#id11">8</a>]</dt> <dd>core-workflow mailing list (<a class="reference external" href="https://mail.python.org/mailman/listinfo/core-workflow">https://mail.python.org/mailman/listinfo/core-workflow</a>)</aside> <aside class="footnote brackets" id="guido-keynote" role="doc-footnote"> <dt class="label" id="guido-keynote">[<a href="#id12">9</a>]</dt> <dd>Guido van Rossum’s keynote at PyCon US (<a class="reference external" href="https://www.youtube.com/watch?v=G-uKNd5TSBw">https://www.youtube.com/watch?v=G-uKNd5TSBw</a>)</aside> <aside class="footnote brackets" id="reasons" role="doc-footnote"> <dt class="label" id="reasons">[<a href="#id13">10</a>]</dt> <dd>Email to core-workflow outlining reasons why GitHub was selected (<a class="reference external" href="https://mail.python.org/pipermail/core-workflow/2016-January/000345.html">https://mail.python.org/pipermail/core-workflow/2016-January/000345.html</a>)</aside> <aside class="footnote brackets" id="benchmarks-repo" role="doc-footnote"> <dt class="label" id="benchmarks-repo">[<a href="#id18">11</a>]</dt> <dd>Mercurial repository for the Unified Benchmark Suite (<a class="reference external" href="https://hg.python.org/benchmarks/">https://hg.python.org/benchmarks/</a>)</aside> <aside class="footnote brackets" id="devinabox-repo" role="doc-footnote"> <dt class="label" id="devinabox-repo">[12]<em> (<a href='#id17'>1</a>, <a href='#id64'>2</a>) </em></dt> <dd>Mercurial repository for devinabox (<a class="reference external" href="https://hg.python.org/devinabox/">https://hg.python.org/devinabox/</a>)</aside> <aside class="footnote brackets" id="peps-repo" role="doc-footnote"> <dt class="label" id="peps-repo">[13]<em> (<a href='#id19'>1</a>, <a href='#id35'>2</a>, <a href='#id65'>3</a>) </em></dt> <dd>Mercurial repository of the Python Enhancement Proposals (<a class="reference external" href="https://hg.python.org/peps/">https://hg.python.org/peps/</a>)</aside> <aside class="footnote brackets" id="devguide-repo" role="doc-footnote"> <dt class="label" id="devguide-repo">[14]<em> (<a href='#id20'>1</a>, <a href='#id34'>2</a>, <a href='#id66'>3</a>) </em></dt> <dd>Mercurial repository for the Python Developer’s Guide (<a class="reference external" href="https://hg.python.org/devguide/">https://hg.python.org/devguide/</a>)</aside> <aside class="footnote brackets" id="id75" role="doc-footnote"> <dt class="label" id="id75">[15]<em> (<a href='#id21'>1</a>, <a href='#id37'>2</a>, <a href='#id41'>3</a>, <a href='#id42'>4</a>, <a href='#id67'>5</a>) </em></dt> <dd>Mercurial repository for CPython (<a class="reference external" href="https://hg.python.org/cpython/">https://hg.python.org/cpython/</a>)</aside> <aside class="footnote brackets" id="github-python-org" role="doc-footnote"> <dt class="label" id="github-python-org">[<a href="#id23">16</a>]</dt> <dd>Python organization on GitHub (<a class="reference external" href="https://github.com/python">https://github.com/python</a>)</aside> <aside class="footnote brackets" id="github-org-perms" role="doc-footnote"> <dt class="label" id="github-org-perms">[<a href="#id24">17</a>]</dt> <dd>GitHub repository permission levels (<a class="reference external" href="https://help.github.com/enterprise/2.4/user/articles/repository-permission-levels-for-an-organization/">https://help.github.com/enterprise/2.4/user/articles/repository-permission-levels-for-an-organization/</a>)</aside> <aside class="footnote brackets" id="cla" role="doc-footnote"> <dt class="label" id="cla">[<a href="#id26">18</a>]</dt> <dd>Python Software Foundation Contributor Agreement (<a class="reference external" href="https://www.python.org/psf/contrib/contrib-form/">https://www.python.org/psf/contrib/contrib-form/</a>)</aside> <aside class="footnote brackets" id="news-file" role="doc-footnote"> <dt class="label" id="news-file">[<a href="#id46">19</a>]</dt> <dd><code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> (<a class="reference external" href="https://hg.python.org/cpython/file/default/Misc/NEWS">https://hg.python.org/cpython/file/default/Misc/NEWS</a>)</aside> <aside class="footnote brackets" id="acks-file" role="doc-footnote"> <dt class="label" id="acks-file">[<a href="#id48">20</a>]</dt> <dd><code class="docutils literal notranslate"><span class="pre">Misc/ACKS</span></code> (<a class="reference external" href="https://hg.python.org/cpython/file/default/Misc/ACKS">https://hg.python.org/cpython/file/default/Misc/ACKS</a>)</aside> <aside class="footnote brackets" id="devguide-merge-across-branches" role="doc-footnote"> <dt class="label" id="devguide-merge-across-branches">[<a href="#id47">21</a>]</dt> <dd>Devguide instructions on how to merge across branches (<a class="reference external" href="https://docs.python.org/devguide/committing.html#merging-between-different-branches-within-the-same-major-version">https://docs.python.org/devguide/committing.html#merging-between-different-branches-within-the-same-major-version</a>)</aside> <aside class="footnote brackets" id="pythocat" role="doc-footnote"> <dt class="label" id="pythocat">[<a href="#id15">22</a>]</dt> <dd>Pythocat (<a class="reference external" href="https://octodex.github.com/pythocat">https://octodex.github.com/pythocat</a>)</aside> <aside class="footnote brackets" id="tracker-plans" role="doc-footnote"> <dt class="label" id="tracker-plans">[<a href="#id45">23</a>]</dt> <dd>Wiki page for bugs.python.org feature development (<a class="reference external" href="https://wiki.python.org/moin/TrackerDevelopmentPlanning">https://wiki.python.org/moin/TrackerDevelopmentPlanning</a>)</aside> <aside class="footnote brackets" id="black-knight-sketch" role="doc-footnote"> <dt class="label" id="black-knight-sketch">[24]</dt> <dd>The “Black Knight” sketch from “Monty Python and the Holy Grail” (<a class="reference external" href="https://www.youtube.com/watch?v=dhRUe-gz690">https://www.youtube.com/watch?v=dhRUe-gz690</a>)</aside> <aside class="footnote brackets" id="bridge-of-death-sketch" role="doc-footnote"> <dt class="label" id="bridge-of-death-sketch">[25]</dt> <dd>The “Bridge of Death” sketch from “Monty Python and the Holy Grail” (<a class="reference external" href="https://www.youtube.com/watch?v=cV0tCphFMr8">https://www.youtube.com/watch?v=cV0tCphFMr8</a>)</aside> <aside class="footnote brackets" id="holy-grail" role="doc-footnote"> <dt class="label" id="holy-grail">[26]</dt> <dd>“Monty Python and the Holy Grail” sketches (<a class="reference external" href="https://www.youtube.com/playlist?list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp">https://www.youtube.com/playlist?list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp</a>)</aside> <aside class="footnote brackets" id="killer-rabbit-sketch" role="doc-footnote"> <dt class="label" id="killer-rabbit-sketch">[27]</dt> <dd>“Killer rabbit” sketch from “Monty Python and the Holy Grail” (<a class="reference external" href="https://www.youtube.com/watch?v=Nvs5pqf-DMA&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=11">https://www.youtube.com/watch?v=Nvs5pqf-DMA&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=11</a>)</aside> <aside class="footnote brackets" id="french-taunter-sketch" role="doc-footnote"> <dt class="label" id="french-taunter-sketch">[28]</dt> <dd>“French Taunter” from “Monty Python and the Holy Grail” (<a class="reference external" href="https://www.youtube.com/watch?v=A8yjNbcKkNY&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=13">https://www.youtube.com/watch?v=A8yjNbcKkNY&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=13</a>)</aside> <aside class="footnote brackets" id="constitutional-peasants-sketch" role="doc-footnote"> <dt class="label" id="constitutional-peasants-sketch">[29]</dt> <dd>“Constitutional Peasants” from “Monty Python and the Holy Grail” (<a class="reference external" href="https://www.youtube.com/watch?v=JvKIWjnEPNY&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=14">https://www.youtube.com/watch?v=JvKIWjnEPNY&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=14</a>)</aside> <aside class="footnote brackets" id="ni-sketch" role="doc-footnote"> <dt class="label" id="ni-sketch">[30]</dt> <dd>“Knights Who Say Ni” from “Monty Python and the Holy Grail” (<a class="reference external" href="https://www.youtube.com/watch?v=zIV4poUZAQo&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=15">https://www.youtube.com/watch?v=zIV4poUZAQo&list=PL-Qryc-SVnnu1MvN3r94Y9atpaRuIoGmp&index=15</a>)</aside> <aside class="footnote brackets" id="homu" role="doc-footnote"> <dt class="label" id="homu">[<a href="#id52">31</a>]</dt> <dd>Homu (<a class="reference external" href="http://homu.io/">http://homu.io/</a>)</aside> <aside class="footnote brackets" id="zuul" role="doc-footnote"> <dt class="label" id="zuul">[<a href="#id53">32</a>]</dt> <dd>Zuul (<a class="reference external" href="http://docs.openstack.org/infra/zuul/">http://docs.openstack.org/infra/zuul/</a>)</aside> <aside class="footnote brackets" id="travis" role="doc-footnote"> <dt class="label" id="travis">[<a href="#id55">33</a>]</dt> <dd>Travis (<a class="reference external" href="https://travis-ci.org/">https://travis-ci.org/</a>)</aside> <aside class="footnote brackets" id="codeship" role="doc-footnote"> <dt class="label" id="codeship">[34]</dt> <dd>Codeship (<a class="reference external" href="https://codeship.com/">https://codeship.com/</a>)</aside> <aside class="footnote brackets" id="coverage" role="doc-footnote"> <dt class="label" id="coverage">[35]</dt> <dd>coverage.py (<a class="reference external" href="https://pypi.python.org/pypi/coverage">https://pypi.python.org/pypi/coverage</a>)</aside> <aside class="footnote brackets" id="coveralls" role="doc-footnote"> <dt class="label" id="coveralls">[36]</dt> <dd>Coveralls (<a class="reference external" href="https://coveralls.io/">https://coveralls.io/</a>)</aside> <aside class="footnote brackets" id="codecov" role="doc-footnote"> <dt class="label" id="codecov">[<a href="#id58">37</a>]</dt> <dd>Codecov (<a class="reference external" href="https://codecov.io/">https://codecov.io/</a>)</aside> <aside class="footnote brackets" id="pypatcher" role="doc-footnote"> <dt class="label" id="pypatcher">[<a href="#id56">38</a>]</dt> <dd>Pypatcher (<a class="reference external" href="https://github.com/kushaldas/pypatcher">https://github.com/kushaldas/pypatcher</a>)</aside> <aside class="footnote brackets" id="heroku" role="doc-footnote"> <dt class="label" id="heroku">[<a href="#id32">39</a>]</dt> <dd>Heroku (<a class="reference external" href="https://www.heroku.com/">https://www.heroku.com/</a>)</aside> <aside class="footnote brackets" id="gh-status-check" role="doc-footnote"> <dt class="label" id="gh-status-check">[<a href="#id31">40</a>]</dt> <dd>GitHub status checks (<a class="reference external" href="https://developer.github.com/v3/repos/statuses/">https://developer.github.com/v3/repos/statuses/</a>)</aside> <aside class="footnote brackets" id="ni" role="doc-footnote"> <dt class="label" id="ni">[<a href="#id33">41</a>]</dt> <dd>The Knights Who Say Ni project (<a class="reference external" href="https://github.com/python/the-knights-who-say-ni">https://github.com/python/the-knights-who-say-ni</a>)</aside> </aside> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> <p>This document has been placed in the public domain.</p> </section> </section> <hr class="docutils" /> <p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0512.rst">https://github.com/python/peps/blob/main/peps/pep-0512.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0512.rst">2023-09-09 17:39:29 GMT</a></p> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#repositories-to-migrate">Repositories to Migrate</a></li> <li><a class="reference internal" href="#migration-plan">Migration Plan</a><ul> <li><a class="reference internal" href="#requirements-for-code-only-repositories">Requirements for Code-Only Repositories</a><ul> <li><a class="reference internal" href="#create-a-python-core-team">Create a ‘Python core’ team</a></li> <li><a class="reference internal" href="#define-commands-to-move-a-mercurial-repository-to-git">Define commands to move a Mercurial repository to Git</a></li> <li><a class="reference internal" href="#cla-enforcement">CLA enforcement</a><ul> <li><a class="reference internal" href="#adding-github-username-support-to-bugs-python-org">Adding GitHub username support to bugs.python.org</a></li> <li><a class="reference internal" href="#a-bot-to-enforce-cla-signing">A bot to enforce CLA signing</a></li> </ul> </li> <li><a class="reference internal" href="#make-old-repository-read-only">Make old repository read-only</a></li> </ul> </li> <li><a class="reference internal" href="#requirements-for-web-related-repositories">Requirements for Web-Related Repositories</a></li> <li><a class="reference internal" href="#requirements-for-the-cpython-repository">Requirements for the cpython Repository</a><ul> <li><a class="reference internal" href="#document-steps-to-commit-a-pull-request">Document steps to commit a pull request</a></li> <li><a class="reference internal" href="#linking-pull-requests-to-issues">Linking pull requests to issues</a><ul> <li><a class="reference internal" href="#linking-a-pull-request-to-an-issue">Linking a pull request to an issue</a></li> <li><a class="reference internal" href="#notify-the-issue-if-a-commit-is-made">Notify the issue if a commit is made</a></li> </ul> </li> <li><a class="reference internal" href="#update-the-linking-service-for-mapping-commit-ids-to-urls">Update the linking service for mapping commit IDs to URLs</a></li> <li><a class="reference internal" href="#deprecate-sys-mercurial">Deprecate sys._mercurial</a></li> <li><a class="reference internal" href="#update-the-devguide">Update the devguide</a></li> <li><a class="reference internal" href="#update-pep-101">Update PEP 101</a></li> </ul> </li> <li><a class="reference internal" href="#optional-planned-features">Optional, Planned Features</a><ul> <li><a class="reference internal" href="#handling-misc-news">Handling Misc/NEWS</a></li> <li><a class="reference internal" href="#handling-misc-acks">Handling Misc/ACKS</a></li> <li><a class="reference internal" href="#create-https-git-python-org">Create <code class="docutils literal notranslate"><span class="pre">https://git.python.org</span></code></a></li> <li><a class="reference internal" href="#backup-of-pull-request-data">Backup of pull request data</a></li> <li><a class="reference internal" href="#bot-to-generate-cherry-pick-pull-requests">Bot to generate cherry-pick pull requests</a></li> <li><a class="reference internal" href="#pull-request-commit-queue">Pull request commit queue</a></li> <li><a class="reference internal" href="#a-ci-service">A CI service</a></li> <li><a class="reference internal" href="#test-coverage-report">Test coverage report</a></li> <li><a class="reference internal" href="#notifying-issues-of-pull-request-comments">Notifying issues of pull request comments</a></li> <li><a class="reference internal" href="#allow-bugs-python-org-to-use-github-as-a-login-provider">Allow bugs.python.org to use GitHub as a login provider</a></li> <li><a class="reference internal" href="#web-hooks-for-re-generating-web-content">Web hooks for re-generating web content</a></li> <li><a class="reference internal" href="#link-web-content-back-to-files-that-it-is-generated-from">Link web content back to files that it is generated from</a></li> <li><a class="reference internal" href="#splitting-out-parts-of-the-documentation-into-their-own-repositories">Splitting out parts of the documentation into their own repositories</a></li> <li><a class="reference internal" href="#backup-of-git-repositories">Backup of Git repositories</a></li> <li><a class="reference internal" href="#identify-potential-new-core-developers">Identify potential new core developers</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#status">Status</a><ul> <li><a class="reference internal" href="#cpython-repo">cpython repo </a></li> </ul> </li> <li><a class="reference internal" href="#open-issues">Open Issues</a><ul> <li><a class="reference internal" href="#the-fate-of-hg-python-org">The fate of hg.python.org</a></li> <li><a class="reference internal" href="#git-cli-commands-for-committing-a-pull-request-to-cpython">Git CLI commands for committing a pull request to cpython</a></li> <li><a class="reference internal" href="#naming-the-bots">Naming the bots</a></li> </ul> </li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#separate-python-2-and-python-3-repositories">Separate Python 2 and Python 3 repositories</a></li> <li><a class="reference internal" href="#commit-multi-release-changes-in-bugfix-branch-first">Commit multi-release changes in bugfix branch first</a></li> <li><a class="reference internal" href="#deriving-misc-news-from-the-commit-logs">Deriving <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> from the commit logs</a></li> <li><a class="reference internal" href="#deriving-misc-news-from-bugs-python-org">Deriving <code class="docutils literal notranslate"><span class="pre">Misc/NEWS</span></code> from bugs.python.org</a></li> </ul> </li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <br> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0512.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>