Update PEP 474 for my change in role

pep-0474.txt

@@ -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
+As of July 2015, I now work for Red Hat as a software development workflow
-worked since September 1998) to Red Hat back in June 2011 , I now work for
+designer and process architect, focusing on the upstream developer experience
-Red Hat as a software development workflow designer and process architect,
+in Fedora. Two of the key pieces of that experience will be familiar to many
-focusing on the open source cross-platform
+web service developers: Docker for local container management, and Vagrant for
-`Atomic Developer Bundle <https://github.com/projectatomic/adb-atomic-developer-bundle>`__,
+cross-platform local development VM management. Spending time applying these
-which is part of the tooling ecosystem for the
+technologies in multiple upstream contexts helps provide additional insight
-`Project Atomic <http://www.projectatomic.io/>`__ container hosting platform.
+into what works well and what still needs further improvement to provide a good
-Two of the key pieces of that bundle will be familiar to many readers:
+software development experience that is well integrated on Fedora, but also
-Docker for container management, and Vagrant for cross-platform local
+readily available on other Linux distributions, Windows, Mac OS X.
-development VM management.
 
-However, rather than being a developer for the downstream Red Hat Enterprise
+In relation to code review workflows in particular, the primary code review
-Linux Container Development Kit, I work with the development teams for a
+workflow management tools I've used in my career are
-range of Red Hat's internal services, encouraging the standardisation of
+Gerrit (for multi-step code review with fine-grained access control), GitHub
-internal development tooling and processes on the Atomic Developer Bundle,
+and BitBucket (for basic pull request based workflows), and Rietveld (for
-contributing upstream as required to ensure it meets our needs and
+CPython's optional pre-commit reviews).
-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
+Kallithea is interesting as a base project to build, as it's currently a
-Bundle with tools and technologies used across Red Hat's project and product
+combined repo hosting and code review management platform, but doesn't
-portfolio. As Red Hat is an open source system integrator, that means
+directly integrate the two by offering online merges. This creates the
-touching on a wide range of services and technologies, including GitHub,
+opportunity to blend the low barrier to entry benefits of the GitHub/BitBucket
-GerritHub, standalone Gerrit, GitLab, Bugzilla, JIRA, Jenkins, Docker,
+pull request model with the mentoring and task hand-off benefits of Gerrit
-Kubernetes, OpenShift, OpenStack, oVirt, Ansible, Puppet, and more.
+in defining a online code merging model for Kallithea in collaboration with
-
+the upstream Kallithea developers.
-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
@@ -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