PEP 474: Document why *I* care about this PEP
This commit is contained in:
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
|
The richer administrative functionality would also make it substantially
|
||||||
easier to grant users access to particular repositories for collaboration
|
easier to grant users access to particular repositories for collaboration
|
||||||
purposes, without having to grant them general access to the entire
|
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
|
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.
|
specifically aimed at developers running local VMs for testing purposes.
|
||||||
The `Vagrant based development guidelines
|
The `Vagrant based development guidelines
|
||||||
<http://www.openshift.org/documentation/oo_deployment_guide_vagrant.html>`__
|
<http://www.openshift.org/documentation/oo_deployment_guide_vagrant.html>`__
|
||||||
for
|
for OpenShift Origin provide an extended example of the kind of workflow this
|
||||||
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
|
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
|
for working with a local build of the `main python.org website
|
||||||
<https://github.com/python/pythondotorg#using-vagrant>`__.
|
<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.
|
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
|
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
|
Prior to acceptance, in the absence of transparent interoperability, this PEP
|
||||||
should propose specific recommendations for inclusion in the CPython
|
should propose specific recommendations for inclusion in the CPython
|
||||||
developer's guide for using git-hg to create pull requests against
|
developer's guide section for
|
||||||
forge.python.org hosted Mercurial repositories.
|
`git users <https://docs.python.org/devguide/gitdevs.html>`__ for creating
|
||||||
|
pull requests against forge.python.org hosted Mercurial repositories.
|
||||||
|
|
||||||
|
|
||||||
Pilot Objectives and Timeline
|
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
|
* May 1: Brett's decision on which proposal to accept
|
||||||
* Sep 13: Python 3.5 released, adopting new workflows for Python 3.6
|
* 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
|
If this proposal is selected for further development, it is proposed to start
|
||||||
of this PEP completed:
|
with the rollout of the following pilot deployment:
|
||||||
|
|
||||||
* a reference implementation operational at kallithea-pilot.python.org,
|
* a reference implementation operational at kallithea-pilot.python.org,
|
||||||
containing at least the developer guide and PEP repositories. This will
|
containing at least the developer guide and PEP repositories. This will
|
||||||
be a "throwaway" instance, allowing core developers and other contributors
|
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.
|
the repository history.
|
||||||
* read-only live mirrors of the Kallithea hosted repositories on GitHub and
|
* read-only live mirrors of the Kallithea hosted repositories on GitHub and
|
||||||
BitBucket. As with the pilot service itself, these would be temporary repos,
|
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
|
process to be based on the relocated Mercurial repos
|
||||||
|
|
||||||
The following items would be objectives of the overall workflow improvement
|
The following items would be objectives of the overall workflow improvement
|
||||||
process, but may not be completed before the Python Language summit, and are
|
process, but are considered "desirable, but not essential" for the initial
|
||||||
also considered "desirable, but not essential" for the initial adoption of
|
adoption of the new service in September (if this proposal is the one
|
||||||
the new service in September (if this proposal is the one selected):
|
selected and the proposed pilot deployment is successful):
|
||||||
|
|
||||||
* allowing the use of python-social-auth to authenticate against the PSF
|
* allowing the use of python-social-auth to authenticate against the PSF
|
||||||
hosted Kallithea instance
|
hosted Kallithea instance
|
||||||
|
|
Loading…
Reference in New Issue