PEP 474 - Creating forge.python.org

PEP: 474
Title: Creating forge.python.org
Version: e2394256edf2
Last-Modified: 2014-09-23 19:44:33 +1000 (Tue, 23 Sep 2014)
Author: Nick Coghlan <ncoghlan at gmail.com>
Status: Deferred
Type: Process
Created: 19-Jul-2014
Post-History: 19-Jul-2014

Abstract

This PEP proposes setting up a new PSF provided resource, forge.python.org, as a location for maintaining various supporting repositories (such as the repository for Python Enhancement Proposals) in a way that is more accessible to new contributors, and easier to manage for core developers.

This PEP does not propose any changes to the core development workflow for CPython itself (see PEP 462 in relation to that).

PEP Deferral

This PEP is deferred largely because I don't currently have time to work on it. If anyone would like to take it over, let me know.

Proposal

This PEP proposes that, once the Kallithea project has made an official release, that a Kallithea instance be deployed as "forge.python.org".

Individual repositories (such as the developer guide or the PEPs repository) may then be migrated from the existing hg.python.org infrastructure to the new forge.python.org infrastructure on a case by case basis. Each migration will need to decide whether to retain a read-only mirror on hg.python.org, or whether to just migrate wholesale to the new location.

This would not be a general purpose hosting site for arbitrary Python projects, but a more narrowly focused site akin to the existing hg.python.org.

Rationale

Currently, hg.python.org hosts more than just the core CPython repository, it also hosts other repositories such as those for the CPython developer guide and for Python Enhancement Proposals, along with various "sandbox" repositories for core developer experimentation.

While the simple "pull request" style workflow made popular by code hosting sites like GitHub and BitBucket isn't adequate for the complex branching model needed for parallel maintenance and development of the various CPython releases, it's a good fit for several of the ancillary projects that surround CPython that we don't wish to move to a proprietary hosting site.

The key requirements proposed for a PSF provided software forge are:

  • Must support self-hosting on PSF infrastructure without ongoing fees
  • Must support Mercurial (for consistency with existing tooling)
  • Must support simple "pull request" style workflows
  • Must support online editing for simple changes

Ideally, the chosen solution would also be a fully open source application written in Python.

The requirement for self-hosting without ongoing fees rules out the free-as-in-beer providers like GitHub and BitBucket, in addition to the various proprietary source code management offerings.

The requirement for Mercurial support not only rules out GitHub, but also other Git-only solutions like GitLab and Gitorious.

The requirement for online editing support rules out the Apache Allura/HgForge combination.

That leaves two main contenders from a technical perspective:

The legal uncertainty over the interaction between RhodeCode's current "Business Source" licensing model and the various GPL components it relies on currently make it unclear whether it is legally permissible to deploy it.

By contrast, Kallithea is a full GPLv3 application (derived from the clearly and unambiguously GPLv3 licensed components of RhodeCode) that is being developed under the auspices of the Software Freedom Conservancy . The Conservancy has affirmed that the Kallithea codebase is completely and validly licensed under GPLv3. In addition to their role in building the initial Kallithea community, the Conservancy is also the legal home of both the Mercurial and Git projects. Other SFC member projects that may be familiar to Python users include Twisted, Gevent, BuildBot and PyPy.

Perceived Benefits

The primary benefit of deploying Kallithea as forge.python.org is that supporting repositories such as the developer guide and the PEP repo could potentially be managed using pull requests and online editing. This would be much simpler than the current workflow which requires PEP editors and other core developers to act as intermediaries to apply updates suggested by other users.

The richer administrative functionality would also make it substantially easier to grant users access to particular repositories for collaboration purposes, without having to grant them general access to the entire installation.

Technical Challenges

User account management

Ideally we'd be able to offer a single account that spans all python.org services, including Kallithea, Roundup/Rietveld, PyPI and the back end for the new python.org site, but actually implementing that would be a distinct infrastructure project, independent of this PEP.

A potentially simpler near term solution would be if Kallithea's user account management could be integrated with the existing account management in Roundup, similar to what was done for Rietveld. However, if that also turns out to be impractical in the near term, we would merely end up with another identity silo to be integrated at a later date, suggesting that this doesn't need to be considered a blocker for an initial Kallithea deployment.

Source: https://hg.python.org/peps/file/tip/pep-0474.txt

Notice: While Javascript is not essential for this website, your interaction with the content will be limited. Please turn Javascript on for the full experience.