[Python-checkins] peps: PEP 474: Document why *I* care about this PEP

[nick.coghlan]

https://hg.python.org/peps/rev/8adee3dfda69
changeset:   5748:8adee3dfda69
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Fri Apr 03 14:54:15 2015 +1000
summary:
  PEP 474: Document why *I* care about this PEP

files:
  pep-0474.txt |  77 +++++++++++++++++++++++++++++++++------
  1 files changed, 65 insertions(+), 12 deletions(-)


diff --git a/pep-0474.txt b/pep-0474.txt
--- a/pep-0474.txt
+++ b/pep-0474.txt
@@ -133,8 +133,9 @@
 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 @@
 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 @@
 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 @@
 
 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 @@
 * 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 @@
   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

-- 
Repository URL: https://hg.python.org/peps