[Python-checkins] peps: Update PEP 474 for my change in role

Sat Aug 8 16:52:44 CEST 2015

https://hg.python.org/peps/rev/817c0e251e34
changeset:   5935:817c0e251e34
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Aug 09 00:52:37 2015 +1000
summary:
  Update PEP 474 for my change in role

files:
  pep-0474.txt |  97 ++++++++++++---------------------------
  1 files changed, 30 insertions(+), 67 deletions(-)

diff --git a/pep-0474.txt b/pep-0474.txt
--- a/pep-0474.txt
+++ b/pep-0474.txt
@@ -76,21 +76,23 @@
 * 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 @@
 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 @@
 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

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