PEP 474: Document why *I* care about this PEP
This commit is contained in:
Nick Coghlan
parent
53883a914a
commit
bab89a734b
77
pep-0474.txt
77
pep-0474.txt
|
|
@ -133,8 +133,9 @@ 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.
|
||||
|
||||
installation. This helps lower barriers to entry, as trust can more
|
||||
readily be granted and earned incrementally, rather than being an
|
||||
all-or-nothing decision around granting core developer access.
|
||||
|
||||
Sustaining Engineering Considerations
|
||||
=====================================
|
||||
|
|
@ -191,8 +192,7 @@ Vagrant, which is a popular automated virtual machine management system
|
|||
specifically aimed at developers running local VMs for testing purposes.
|
||||
The `Vagrant based development guidelines
|
||||
<http://www.openshift.org/documentation/oo_deployment_guide_vagrant.html>`__
|
||||
for
|
||||
OpenShift Origin provide an extended example of the kind of workflow this
|
||||
for OpenShift Origin provide an extended example of the kind of workflow this
|
||||
approach enables. It's also worth noting that Vagrant is one of the options
|
||||
for working with a local build of the `main python.org website
|
||||
<https://github.com/python/pythondotorg#using-vagrant>`__.
|
||||
|
|
@ -223,6 +223,58 @@ 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.
|
||||
|
||||
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 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.
|
||||
|
||||
|
||||
Technical Concerns and Challenges
|
||||
=================================
|
||||
|
||||
|
|
@ -358,8 +410,9 @@ GitHub and Atlassian's paying customers.
|
|||
|
||||
Prior to acceptance, in the absence of transparent interoperability, this PEP
|
||||
should propose specific recommendations for inclusion in the CPython
|
||||
developer's guide for using git-hg to create pull requests against
|
||||
forge.python.org hosted Mercurial repositories.
|
||||
developer's guide section for
|
||||
`git users <https://docs.python.org/devguide/gitdevs.html>`__ for creating
|
||||
pull requests against forge.python.org hosted Mercurial repositories.
|
||||
|
||||
|
||||
Pilot Objectives and Timeline
|
||||
|
|
@ -375,13 +428,13 @@ workflow. Key dates in that timeline are:
|
|||
* May 1: Brett's decision on which proposal to accept
|
||||
* Sep 13: Python 3.5 released, adopting new workflows for Python 3.6
|
||||
|
||||
Prior to the April 8 discussion, it is proposed to have the following aspects
|
||||
of this PEP completed:
|
||||
If this proposal is selected for further development, it is proposed to start
|
||||
with the rollout of the following pilot deployment:
|
||||
|
||||
* a reference implementation operational at kallithea-pilot.python.org,
|
||||
containing at least the developer guide and PEP repositories. This will
|
||||
be a "throwaway" instance, allowing core developers and other contributors
|
||||
to experiement freely without worrying about the long term consequences for
|
||||
to experiment freely without worrying about the long term consequences for
|
||||
the repository history.
|
||||
* read-only live mirrors of the Kallithea hosted repositories on GitHub and
|
||||
BitBucket. As with the pilot service itself, these would be temporary repos,
|
||||
|
|
@ -403,9 +456,9 @@ part of the pilot:
|
|||
process to be based on the relocated Mercurial repos
|
||||
|
||||
The following items would be objectives of the overall workflow improvement
|
||||
process, but may not be completed before the Python Language summit, and are
|
||||
also considered "desirable, but not essential" for the initial adoption of
|
||||
the new service in September (if this proposal is the one selected):
|
||||
process, but are considered "desirable, but not essential" for the initial
|
||||
adoption of the new service in September (if this proposal is the one
|
||||
selected and the proposed pilot deployment is successful):
|
||||
|
||||
* allowing the use of python-social-auth to authenticate against the PSF
|
||||
hosted Kallithea instance
|
||||
|
|
|
|||
Loading…
Reference in New Issue