mirror of https://github.com/python/peps
455 lines
29 KiB
HTML
455 lines
29 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 481 – Migrate CPython to Git, Github, and Phabricator | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0481/">
|
||
<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 481 – Migrate CPython to Git, Github, and Phabricator | peps.python.org'>
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0481/">
|
||
<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="Python Enhancement Proposals (PEPs)">
|
||
<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 481</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 481 – Migrate CPython to Git, Github, and Phabricator</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Donald Stufft <donald at stufft.io></dd>
|
||
<dt class="field-even">Status<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Removed from consideration by sponsor or authors">Withdrawn</abbr></dd>
|
||
<dt class="field-odd">Type<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Normative PEP describing or proposing a change to a Python community process, workflow or governance">Process</abbr></dd>
|
||
<dt class="field-even">Created<span class="colon">:</span></dt>
|
||
<dd class="field-even">29-Nov-2014</dd>
|
||
<dt class="field-odd">Post-History<span class="colon">:</span></dt>
|
||
<dd class="field-odd">29-Nov-2014</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><ul>
|
||
<li><a class="reference internal" href="#version-control-system">Version Control System</a></li>
|
||
<li><a class="reference internal" href="#repository-hosting">Repository Hosting</a></li>
|
||
<li><a class="reference internal" href="#code-review">Code Review</a><ul>
|
||
<li><a class="reference internal" href="#github-pull-requests">GitHub Pull Requests</a></li>
|
||
<li><a class="reference internal" href="#phabricator">Phabricator</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#criticism">Criticism</a><ul>
|
||
<li><a class="reference internal" href="#x-is-not-written-in-python">X is not written in Python</a></li>
|
||
<li><a class="reference internal" href="#github-is-not-free-open-source">GitHub is not Free/Open Source</a></li>
|
||
<li><a class="reference internal" href="#mercurial-is-better-than-git">Mercurial is better than Git</a></li>
|
||
<li><a class="reference internal" href="#cpython-workflow-is-too-complicated">CPython Workflow is too Complicated</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#example-scientific-python">Example: Scientific Python</a></li>
|
||
<li><a class="reference internal" href="#references">References</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<section id="abstract">
|
||
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
||
<div class="admonition note">
|
||
<p class="admonition-title">Note</p>
|
||
<p>This PEP has been withdrawn, if you’re looking for the PEP
|
||
documenting the move to Github, please refer to <a class="pep reference internal" href="../pep-0512/" title="PEP 512 – Migrating from hg.python.org to GitHub">PEP 512</a>.</p>
|
||
</div>
|
||
<p>This PEP proposes migrating the repository hosting of CPython and the
|
||
supporting repositories to Git and Github. It also proposes adding Phabricator
|
||
as an alternative to Github Pull Requests to handle reviewing changes. This
|
||
particular PEP is offered as an alternative to <a class="pep reference internal" href="../pep-0474/" title="PEP 474 – Creating forge.python.org">PEP 474</a> and <a class="pep reference internal" href="../pep-0462/" title="PEP 462 – Core development workflow automation for CPython">PEP 462</a> which aims
|
||
to achieve the same overall benefits but restricts itself to tools that support
|
||
Mercurial and are completely Open Source.</p>
|
||
</section>
|
||
<section id="rationale">
|
||
<h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2>
|
||
<p>CPython is an open source project which relies on a number of volunteers
|
||
donating their time. As an open source project it relies on attracting new
|
||
volunteers as well as retaining existing ones in order to continue to have
|
||
a healthy amount of manpower available. In addition to increasing the amount of
|
||
manpower that is available to the project, it also needs to allow for effective
|
||
use of what manpower <em>is</em> available.</p>
|
||
<p>The current toolchain of the CPython project is a custom and unique combination
|
||
of tools which mandates a workflow that is similar to one found in a lot of
|
||
older projects, but which is becoming less and less popular as time goes on.</p>
|
||
<p>The one-off nature of the CPython toolchain and workflow means that any new
|
||
contributor is going to need spend time learning the tools and workflow before
|
||
they can start contributing to CPython. Once a new contributor goes through
|
||
the process of learning the CPython workflow they also are unlikely to be able
|
||
to take that knowledge and apply it to future projects they wish to contribute
|
||
to. This acts as a barrier to contribution which will scare off potential new
|
||
contributors.</p>
|
||
<p>In addition the tooling that CPython uses is under-maintained, antiquated,
|
||
and it lacks important features that enable committers to more effectively use
|
||
their time when reviewing and approving changes. The fact that it is
|
||
under-maintained means that bugs are likely to last for longer, if they ever
|
||
get fixed, as well as it’s more likely to go down for extended periods of time.
|
||
The fact that it is antiquated means that it doesn’t effectively harness the
|
||
capabilities of the modern web platform. Finally the fact that it lacks several
|
||
important features such as a lack of pre-testing commits and the lack of an
|
||
automatic merge tool means that committers have to do needless busy work to
|
||
commit even the simplest of changes.</p>
|
||
<section id="version-control-system">
|
||
<h3><a class="toc-backref" href="#version-control-system" role="doc-backlink">Version Control System</a></h3>
|
||
<p>The first decision that needs to be made is the VCS of the primary server side
|
||
repository. Currently the CPython repository, as well as a number of supporting
|
||
repositories, uses Mercurial. When evaluating the VCS we must consider the
|
||
capabilities of the VCS itself as well as the network effect and mindshare of
|
||
the community around that VCS.</p>
|
||
<p>There are really only two real options for this, Mercurial and Git. Between the
|
||
two of them the technical capabilities are largely equivalent. For this reason
|
||
this PEP will largely ignore the technical arguments about the VCS system and
|
||
will instead focus on the social aspects.</p>
|
||
<p>It is not possible to get exact numbers for the number of projects or people
|
||
which are using a particular VCS, however we can infer this by looking at
|
||
several sources of information for what VCS projects are using.</p>
|
||
<p>The Open Hub (previously Ohloh) statistics <a class="footnote-reference brackets" href="#openhub-stats" id="id1">[1]</a> show that 37% of
|
||
the repositories indexed by The Open Hub are using Git (second only to SVN
|
||
which has 48%) while Mercurial has just 2% (beating only bazaar which has 1%).
|
||
This has Git being just over 18 times as popular as Mercurial on The Open Hub.</p>
|
||
<p>Another source of information on the popular of the difference VCSs is PyPI
|
||
itself. This source is more targeted at the Python community itself since it
|
||
represents projects developed for Python. Unfortunately PyPI does not have a
|
||
standard location for representing this information, so this requires manual
|
||
processing. If we limit our search to the top 100 projects on PyPI (ordered
|
||
by download counts) we can see that 62% of them use Git while 22% of them use
|
||
Mercurial while 13% use something else. This has Git being just under 3 times
|
||
as popular as Mercurial for the top 100 projects on PyPI.</p>
|
||
<p>Obviously from these numbers Git is by far the more popular DVCS for open
|
||
source projects and choosing the more popular VCS has a number of positive
|
||
benefits.</p>
|
||
<p>For new contributors it increases the likelihood that they will have already
|
||
learned the basics of Git as part of working with another project or if they
|
||
are just now learning Git, that they’ll be able to take that knowledge and
|
||
apply it to other projects. Additionally a larger community means more people
|
||
writing how to guides, answering questions, and writing articles about Git
|
||
which makes it easier for a new user to find answers and information about
|
||
the tool they are trying to learn.</p>
|
||
<p>Another benefit is that by nature of having a larger community, there will be
|
||
more tooling written <em>around</em> it. This increases options for everything from
|
||
GUI clients, helper scripts, repository hosting, etc.</p>
|
||
</section>
|
||
<section id="repository-hosting">
|
||
<h3><a class="toc-backref" href="#repository-hosting" role="doc-backlink">Repository Hosting</a></h3>
|
||
<p>This PEP proposes allowing GitHub Pull Requests to be submitted, however GitHub
|
||
does not have a way to submit Pull Requests against a repository that is not
|
||
hosted on GitHub. This PEP also proposes that in addition to GitHub Pull
|
||
Requests Phabricator’s Differential app can also be used to submit proposed
|
||
changes and Phabricator <em>does</em> allow submitting changes against a repository
|
||
that is not hosted on Phabricator.</p>
|
||
<p>For this reason this PEP proposes using GitHub as the canonical location of
|
||
the repository with a read-only mirror located in Phabricator. If at some point
|
||
in the future GitHub is no longer desired, then repository hosting can easily
|
||
be moved to solely in Phabricator and the ability to accept GitHub Pull
|
||
Requests dropped.</p>
|
||
<p>In addition to hosting the repositories on Github, a read only copy of all
|
||
repositories will also be mirrored onto the PSF Infrastructure.</p>
|
||
</section>
|
||
<section id="code-review">
|
||
<h3><a class="toc-backref" href="#code-review" role="doc-backlink">Code Review</a></h3>
|
||
<p>Currently CPython uses a custom fork of Rietveld which has been modified to
|
||
not run on Google App Engine which is really only able to be maintained
|
||
currently by one person. In addition it is missing out on features that are
|
||
present in many modern code review tools.</p>
|
||
<p>This PEP proposes allowing both Github Pull Requests and Phabricator changes
|
||
to propose changes and review code. It suggests both so that contributors can
|
||
select which tool best enables them to submit changes, and reviewers can focus
|
||
on reviewing changes in the tooling they like best.</p>
|
||
<section id="github-pull-requests">
|
||
<h4><a class="toc-backref" href="#github-pull-requests" role="doc-backlink">GitHub Pull Requests</a></h4>
|
||
<p>GitHub is a very popular code hosting site and is increasingly becoming the
|
||
primary place people look to contribute to a project. Enabling users to
|
||
contribute through GitHub is enabling contributors to contribute using tooling
|
||
that they are likely already familiar with and if they are not they are likely
|
||
to be able to apply to another project.</p>
|
||
<p>GitHub Pull Requests have a fairly major advantage over the older “submit a
|
||
patch to a bug tracker” model. It allows developers to work completely within
|
||
their VCS using standard VCS tooling so it does not require creating a patch
|
||
file and figuring out what the right location is to upload it to. This lowers
|
||
the barrier for sending a change to be reviewed.</p>
|
||
<p>On the reviewing side, GitHub Pull Requests are far easier to review, they have
|
||
nice syntax highlighted diffs which can operate in either unified or side by
|
||
side views. They allow expanding the context on a diff up to and including the
|
||
entire file. Finally they allow commenting inline and on the pull request as
|
||
a whole and they present that in a nice unified way which will also hide
|
||
comments which no longer apply. Github also provides a “rendered diff” view
|
||
which enables easily viewing a diff of rendered markup (such as rst) instead
|
||
of needing to review the diff of the raw markup.</p>
|
||
<p>The Pull Request work flow also makes it trivial to enable the ability to
|
||
pre-test a change before actually merging it. Any particular pull request can
|
||
have any number of different types of “commit statuses” applied to it, marking
|
||
the commit (and thus the pull request) as either in a pending, successful,
|
||
errored, or failure state. This makes it easy to see inline if the pull request
|
||
is passing all of the tests, if the contributor has signed a CLA, etc.</p>
|
||
<p>Actually merging a Github Pull Request is quite simple, a core reviewer simply
|
||
needs to press the “Merge” button once the status of all the checks on the
|
||
Pull Request are green for successful.</p>
|
||
<p>GitHub also has a good workflow for submitting pull requests to a project
|
||
completely through their web interface. This would enable the Python
|
||
documentation to have “Edit on GitHub” buttons on every page and people who
|
||
discover things like typos, inaccuracies, or just want to make improvements to
|
||
the docs they are currently writing can simply hit that button and get an in
|
||
browser editor that will let them make changes and submit a pull request all
|
||
from the comfort of their browser.</p>
|
||
</section>
|
||
<section id="phabricator">
|
||
<h4><a class="toc-backref" href="#phabricator" role="doc-backlink">Phabricator</a></h4>
|
||
<p>In addition to GitHub Pull Requests this PEP also proposes setting up a
|
||
Phabricator instance and pointing it at the GitHub hosted repositories. This
|
||
will allow utilizing the Phabricator review applications of Differential and
|
||
Audit.</p>
|
||
<p>Differential functions similarly to GitHub pull requests except that they
|
||
require installing the <code class="docutils literal notranslate"><span class="pre">arc</span></code> command line tool to upload patches to
|
||
Phabricator.</p>
|
||
<p>Whether to enable Phabricator for any particular repository can be chosen on
|
||
a case-by-case basis, this PEP only proposes that it must be enabled for the
|
||
CPython repository, however for smaller repositories such as the PEP repository
|
||
it may not be worth the effort.</p>
|
||
</section>
|
||
</section>
|
||
</section>
|
||
<section id="criticism">
|
||
<h2><a class="toc-backref" href="#criticism" role="doc-backlink">Criticism</a></h2>
|
||
<section id="x-is-not-written-in-python">
|
||
<h3><a class="toc-backref" href="#x-is-not-written-in-python" role="doc-backlink">X is not written in Python</a></h3>
|
||
<p>One feature that the current tooling (Mercurial, Rietveld) has is that the
|
||
primary language for all of the pieces are written in Python. It is this PEPs
|
||
belief that we should focus on the <em>best</em> tools for the job and not the <em>best</em>
|
||
tools that happen to be written in Python. Volunteer time is a precious
|
||
resource to any open source project and we can best respect and utilize that
|
||
time by focusing on the benefits and downsides of the tools themselves rather
|
||
than what language their authors happened to write them in.</p>
|
||
<p>One concern is the ability to modify tools to work for us, however one of
|
||
the Goals here is to <em>not</em> modify software to work for us and instead adapt
|
||
ourselves to a more standard workflow. This standardization pays off in the
|
||
ability to re-use tools out of the box freeing up developer time to actually
|
||
work on Python itself as well as enabling knowledge sharing between projects.</p>
|
||
<p>However, if we do need to modify the tooling, Git itself is largely written in
|
||
C the same as CPython itself is. It can also have commands written for it using
|
||
any language, including Python. Phabricator is written in PHP which is a fairly
|
||
common language in the web world and fairly easy to pick up. GitHub itself is
|
||
largely written in Ruby but given that it’s not Open Source there is no ability
|
||
to modify it so it’s implementation language is completely meaningless.</p>
|
||
</section>
|
||
<section id="github-is-not-free-open-source">
|
||
<h3><a class="toc-backref" href="#github-is-not-free-open-source" role="doc-backlink">GitHub is not Free/Open Source</a></h3>
|
||
<p>GitHub is a big part of this proposal and someone who tends more to ideology
|
||
rather than practicality may be opposed to this PEP on that grounds alone. It
|
||
is this PEPs belief that while using entirely Free/Open Source software is an
|
||
attractive idea and a noble goal, that valuing the time of the contributors by
|
||
giving them good tooling that is well maintained and that they either already
|
||
know or if they learn it they can apply to other projects is a more important
|
||
concern than treating whether something is Free/Open Source is a hard
|
||
requirement.</p>
|
||
<p>However, history has shown us that sometimes benevolent proprietary companies
|
||
can stop being benevolent. This is hedged against in a few ways:</p>
|
||
<ul class="simple">
|
||
<li>We are not utilizing the GitHub Issue Tracker, both because it is not
|
||
powerful enough for CPython but also because for the primary CPython
|
||
repository the ability to take our issues and put them somewhere else if we
|
||
ever need to leave GitHub relies on GitHub continuing to allow API access.</li>
|
||
<li>We are utilizing the GitHub Pull Request workflow, however all of those
|
||
changes live inside of Git. So a mirror of the GitHub repositories can easily
|
||
contain all of those Pull Requests. We would potentially lose any comments if
|
||
GitHub suddenly turned “evil”, but the changes themselves would still exist.</li>
|
||
<li>We are utilizing the GitHub repository hosting feature, however since this is
|
||
just git moving away from GitHub is as simple as pushing the repository to
|
||
a different location. Data portability for the repository itself is extremely
|
||
high.</li>
|
||
<li>We are also utilizing Phabricator to provide an alternative for people who
|
||
do not wish to use GitHub. This also acts as a fallback option which will
|
||
already be in place if we ever need to stop using GitHub.</li>
|
||
</ul>
|
||
<p>Relying on GitHub comes with a number of benefits beyond just the benefits of
|
||
the platform itself. Since it is a commercially backed venture it has a full-time
|
||
staff responsible for maintaining its services. This includes making sure
|
||
they stay up, making sure they stay patched for various security
|
||
vulnerabilities, and further improving the software and infrastructure as time
|
||
goes on.</p>
|
||
</section>
|
||
<section id="mercurial-is-better-than-git">
|
||
<h3><a class="toc-backref" href="#mercurial-is-better-than-git" role="doc-backlink">Mercurial is better than Git</a></h3>
|
||
<p>Whether Mercurial or Git is better on a technical level is a highly subjective
|
||
opinion. This PEP does not state whether the mechanics of Git or Mercurial is
|
||
better and instead focuses on the network effect that is available for either
|
||
option. Since this PEP proposes switching to Git this leaves the people who
|
||
prefer Mercurial out, however those users can easily continue to work with
|
||
Mercurial by using the hg-git <a class="footnote-reference brackets" href="#hg-git" id="id2">[2]</a> extension for Mercurial which will
|
||
let it work with a repository which is Git on the serverside.</p>
|
||
</section>
|
||
<section id="cpython-workflow-is-too-complicated">
|
||
<h3><a class="toc-backref" href="#cpython-workflow-is-too-complicated" role="doc-backlink">CPython Workflow is too Complicated</a></h3>
|
||
<p>One sentiment that came out of previous discussions was that the multi branch
|
||
model of CPython was too complicated for Github Pull Requests. It is the belief
|
||
of this PEP that statement is not accurate.</p>
|
||
<p>Currently any particular change requires manually creating a patch for 2.7 and
|
||
3.x which won’t change at all in this regards.</p>
|
||
<p>If someone submits a fix for the current stable branch (currently 3.4) the
|
||
GitHub Pull Request workflow can be used to create, in the browser, a Pull
|
||
Request to merge the current stable branch into the master branch (assuming
|
||
there is no merge conflicts). If there is a merge conflict that would need to
|
||
be handled locally. This provides an improvement over the current situation
|
||
where the merge must always happen locally.</p>
|
||
<p>Finally if someone submits a fix for the current development branch currently
|
||
then this has to be manually applied to the stable branch if it desired to
|
||
include it there as well. This must also happen locally as well in the new
|
||
workflow, however for minor changes it could easily be accomplished in the
|
||
GitHub web editor.</p>
|
||
<p>Looking at this, I do not believe that <em>any</em> system can hide the complexities
|
||
involved in maintaining several long running branches. The only thing that the
|
||
tooling can do is make it as easy as possible to submit changes.</p>
|
||
</section>
|
||
</section>
|
||
<section id="example-scientific-python">
|
||
<h2><a class="toc-backref" href="#example-scientific-python" role="doc-backlink">Example: Scientific Python</a></h2>
|
||
<p>One of the key ideas behind the move to both git and Github is that a feature
|
||
of a DVCS, the repository hosting, and the workflow used is the social network
|
||
and size of the community using said tools. We can see this is true by looking
|
||
at an example from a sub-community of the Python community: The Scientific
|
||
Python community. They have already migrated most of the key pieces of the
|
||
SciPy stack onto Github using the Pull Request-based workflow. This process
|
||
started with IPython, and as more projects moved over it became a natural
|
||
default for new projects in the community.</p>
|
||
<p>They claim to have seen a great benefit from this move, in that it enables
|
||
casual contributors to easily move between different projects within their
|
||
sub-community without having to learn a special, bespoke workflow and a
|
||
different toolchain for each project. They’ve found that when people can use
|
||
their limited time on actually contributing instead of learning the different
|
||
tools and workflows, not only do they contribute more to one project, but
|
||
that they also expand out and contribute to other projects. This move has also
|
||
been attributed to the increased tendency for members of that community to go
|
||
so far as publishing their research and educational materials on Github as
|
||
well.</p>
|
||
<p>This example showcases the real power behind moving to a highly popular
|
||
toolchain and workflow, as each variance introduces yet another hurdle for new
|
||
and casual contributors to get past and it makes the time spent learning that
|
||
workflow less reusable with other projects.</p>
|
||
</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="openhub-stats" role="doc-footnote">
|
||
<dt class="label" id="openhub-stats">[<a href="#id1">1</a>]</dt>
|
||
<dd><a class="reference external" href="https://www.openhub.net/repositories/compare">Open Hub Statistics</a></aside>
|
||
<aside class="footnote brackets" id="hg-git" role="doc-footnote">
|
||
<dt class="label" id="hg-git">[<a href="#id2">2</a>]</dt>
|
||
<dd><a class="reference external" href="https://hg-git.github.io/">Hg-Git mercurial plugin</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-0481.rst">https://github.com/python/peps/blob/main/peps/pep-0481.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0481.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><ul>
|
||
<li><a class="reference internal" href="#version-control-system">Version Control System</a></li>
|
||
<li><a class="reference internal" href="#repository-hosting">Repository Hosting</a></li>
|
||
<li><a class="reference internal" href="#code-review">Code Review</a><ul>
|
||
<li><a class="reference internal" href="#github-pull-requests">GitHub Pull Requests</a></li>
|
||
<li><a class="reference internal" href="#phabricator">Phabricator</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#criticism">Criticism</a><ul>
|
||
<li><a class="reference internal" href="#x-is-not-written-in-python">X is not written in Python</a></li>
|
||
<li><a class="reference internal" href="#github-is-not-free-open-source">GitHub is not Free/Open Source</a></li>
|
||
<li><a class="reference internal" href="#mercurial-is-better-than-git">Mercurial is better than Git</a></li>
|
||
<li><a class="reference internal" href="#cpython-workflow-is-too-complicated">CPython Workflow is too Complicated</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#example-scientific-python">Example: Scientific Python</a></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-0481.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> |