python-peps/pep-0474.txt

162 lines
6.0 KiB
Plaintext

PEP: 474
Title: Creating forge.python.org
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <ncoghlan@gmail.com>
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 <https://code.rhodecode.com/rhodecode>`__
* `Kallithea SCM <https://kallithea-scm.org/>`__
The `legal uncertainty
<http://sfconservancy.org/blog/2014/jul/15/why-kallithea/>`__ 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
<http://sfconservancy.org/news/2014/jul/04/kallithea-joins/>`__. The
Conservancy has `affirmed
<http://sfconservancy.org/blog/2014/jul/15/why-kallithea/>`__ 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: