iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update PEP 474 for my change in role

This commit is contained in:
Nick Coghlan 2015-08-09 00:52:37 +10:00
parent 0ed11e5754
commit 10a41bf8b2
1 changed files with 30 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
pep-0474.txt
View File

@ -76,21 +76,23 @@ The key requirements proposed for a PSF provided software forge are:
* MUST support online editing for simple changes
* MUST be backed by an active development organisation (community or
commercial)
* MUST support self-hosting of the master repository on PSF infrastructure
without ongoing fees
Additional recommended requirements that are satisfied by this proposal,
but may be negotiable if a sufficiently compelling alternative is presented:
* SHOULD support self-hosting on PSF infrastructure without ongoing fees
* SHOULD be a fully open source application written in Python
* SHOULD support Mercurial (for consistency with existing tooling)
* SHOULD support Git (to provide that option to users that prefer it)
* SHOULD allow users of git and Mercurial clients to transparently
collaborate on the same repository
* SHOULD allow users of GitHub and BitBucket to submit proposed changes using
the standard pull request workflows offered by those tools
* SHOULD be open to customisation to meet the needs of CPython core
development, including providing a potential path forward for the
proposed migration to a core reviewer model in PEP 462
The preference 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.
@ -203,76 +205,32 @@ CPython infrastructure services, including Roundup, BuildBot, and the main
python.org web site.
Funding of development
----------------------
As several aspects of this proposal and PEP 462 align with various workflow
improvements under consideration for Red Hat's
`Beaker <https://beaker-project.org>`__ open source hardware integration
testing system and other work-related projects, I have arranged to be able
to devote ~1 day a week to working on CPython infrastructure projects.
Together with Rackspace's existing contributions to maintaining the
pypi.python.org infrastructure, I personally believe this arrangement is
indicative of a more general recognition amongst CPython redistributors and
major users of the merit in helping to sustain upstream infrastructure
through direct contributions of developer time, rather than expecting
volunteer contributors to maintain that infrastructure entirely in their
spare time or funding it indirectly through the PSF (with the additional
management overhead that would entail). I consider this a positive trend, and
one that I will continue to encourage as best I can.
Personal Motivation
===================
As of March 2015, having moved from Boeing Defence Australia (where I had
worked since September 1998) to Red Hat back in June 2011 , I now work for
Red Hat as a software development workflow designer and process architect,
focusing on the open source cross-platform
`Atomic Developer Bundle <https://github.com/projectatomic/adb-atomic-developer-bundle>`__,
which is part of the tooling ecosystem for the
`Project Atomic <http://www.projectatomic.io/>`__ container hosting platform.
Two of the key pieces of that bundle will be familiar to many readers:
Docker for container management, and Vagrant for cross-platform local
development VM management.
As of July 2015, I now work for Red Hat as a software development workflow
designer and process architect, focusing on the upstream developer experience
in Fedora. Two of the key pieces of that experience will be familiar to many
web service developers: Docker for local container management, and Vagrant for
cross-platform local development VM management. Spending time applying these
technologies in multiple upstream contexts helps provide additional insight
into what works well and what still needs further improvement to provide a good
software development experience that is well integrated on Fedora, but also
readily available on other Linux distributions, Windows, Mac OS X.
However, rather than being a developer for the downstream Red Hat Enterprise
Linux Container Development Kit, I work with the development teams for a
range of Red Hat's internal services, encouraging the standardisation of
internal development tooling and processes on the Atomic Developer Bundle,
contributing upstream as required to ensure it meets our needs and
expectations. As with other Red Hat community web service development
projects like `PatternFly <https://www.patternfly.org/>`__, this approach
helps enable standardisation across internal services, community projects,
and commercial products, while still leaving individual development teams
with significant scope to appropriately prioritise their process improvement
efforts by focusing on the limitations currently causing the most
difficulties for them and their users.
In relation to code review workflows in particular, the primary code review
workflow management tools I've used in my career are
Gerrit (for multi-step code review with fine-grained access control), GitHub
and BitBucket (for basic pull request based workflows), and Rietveld (for
CPython's optional pre-commit reviews).
In that role, I'll be focusing on effectively integrating the Developer
Bundle with tools and technologies used across Red Hat's project and product
portfolio. As Red Hat is an open source system integrator, that means
touching on a wide range of services and technologies, including GitHub,
GerritHub, standalone Gerrit, GitLab, Bugzilla, JIRA, Jenkins, Docker,
Kubernetes, OpenShift, OpenStack, oVirt, Ansible, Puppet, and more.
However, as noted above in the section on sustaining engineering
considerations, I've also secured agreement to spend a portion of my work
time on similarly applying these cross platforms tools to improving the
developer experience for the maintenance of Python Software Foundation
infrastructure, starting with this proposal for a Kallithea-based
forge.python.org service.
Between them, my day job and my personal open source engagement have given
me visibility into a lot of what the popular source code management
services do well and what they do poorly. While Kallithea certainly has
plenty of flaws of its own, it's the one I consider most *fixable* from a
personal perspective, as it allows me to get directly involved in tailoring
it to meet the needs of the CPython core development community in a way that
wouldn't be possible with a proprietary service like GitHub or BitBucket, or
practical with a PHP-based service like Phabricator or a Ruby-based service
like GitLab.
Kallithea is interesting as a base project to build, as it's currently a
combined repo hosting and code review management platform, but doesn't
directly integrate the two by offering online merges. This creates the
opportunity to blend the low barrier to entry benefits of the GitHub/BitBucket
pull request model with the mentoring and task hand-off benefits of Gerrit
in defining a online code merging model for Kallithea in collaboration with
the upstream Kallithea developers.
Technical Concerns and Challenges
@ -418,6 +376,11 @@ pull requests against forge.python.org hosted Mercurial repositories.
Pilot Objectives and Timeline
=============================
[TODO: Update this section for Brett's revised timeline, which aims to have
a CPython demo repository online by October 31st, to get a better indication
of *future* capabilities once CPython itself migrates over to the new
system, rather than just the support repos]
This proposal is part of Brett Cannon's `current evaluation
<https://mail.python.org/pipermail/python-dev/2014-December/137472.html>`__
of improvement proposals for various aspects of the CPython development