169 lines
6.2 KiB
Plaintext
169 lines
6.2 KiB
Plaintext
PEP: 474
|
|
Title: Creating forge.python.org
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Nick Coghlan <ncoghlan@gmail.com>
|
|
Status: Deferred
|
|
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).
|
|
|
|
|
|
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:
|
|
|
|
* `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:
|