1177 lines
89 KiB
HTML
1177 lines
89 KiB
HTML
|
||
<!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> |