PEP: 474 Title: Creating forge.python.org Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Status: Draft Type: Process Content-Type: text/x-rst 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). 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: * `RhodeCode `__ * `Kallithea SCM `__ 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. Breaking existing SSH access and links for Mercurial repositories ----------------------------------------------------------------- This PEP proposes leaving the existing hg.python.org installation alone, and setting up Kallithea on a new host. This approach minimises the risk of interfering with the development of CPython itself (and any other projects that don't migrate to the new software forge), but does make any migrations of existing repos more disruptive (since existing checkouts will break). Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: