[Python-checkins] peps: PEP 462 updates, include RhodeCode idea
nick.coghlan
python-checkins at python.org
Sun Feb 16 04:44:49 CET 2014
http://hg.python.org/peps/rev/ef8d4e914766
changeset: 5372:ef8d4e914766
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sun Feb 16 13:44:37 2014 +1000
summary:
PEP 462 updates, include RhodeCode idea
files:
pep-0462.txt | 281 ++++++++++++++++++++++++++++++++++----
1 files changed, 245 insertions(+), 36 deletions(-)
diff --git a/pep-0462.txt b/pep-0462.txt
--- a/pep-0462.txt
+++ b/pep-0462.txt
@@ -14,16 +14,21 @@
========
This PEP proposes investing in automation of several of the tedious, time
-consuming activities that are currently required for the core developerment
+consuming activities that are currently required for the core development
team to incorporate changes into CPython. This proposal is intended to
allow core developers to make more effective use of the time they have
available to contribute to CPython, which should also result in an improved
experience for other contributors that are reliant on the core team to get
their changes incorporated.
+This PEP also proposes changes to the way certain supporting repositories
+(such as the repository for Python Enhancement Proposals) are managed to
+make them more accessible to new contributors, and easier to manage for
+core developers.
-Rationale
-=========
+
+Rationale for changes to the core development workflow
+======================================================
The current core developer workflow to merge a new feature into CPython
on a POSIX system "works" as follows:
@@ -114,7 +119,7 @@
afterwards.
There are also many, many opportunities for core developers to make
-mistakes that inconvience others, both in managing the Mercurial branches
+mistakes that inconvenience others, both in managing the Mercurial branches
and in breaking the buildbots without being in a position to fix them
promptly. This both makes the existing core development team cautious in
granting new developers commit access, as well as making those new
@@ -139,7 +144,9 @@
managers (since they may need to enlist assistance cleaning up test
failures prior to a release) and for the developers themselves (since
it creates significant pressure to fix any failures we inadvertently
- introduce right *now*, rather than at a more convenient time).
+ introduce right *now*, rather than at a more convenient time, as well
+ as potentially making ``hg bisect`` more difficult to use if
+ ``hg annotate`` isn't sufficient to identify the source of a new failure).
* For other contributors, a core developer spending time actually getting
changes merged is a developer that isn't reviewing and discussing patches
on the issue tracker or otherwise helping others to contribute effectively.
@@ -151,6 +158,23 @@
the case for OpenStack).
+Rationale for changes to source code repository management
+==========================================================
+
+Currently, hg.python.org hosts more than just the core CPython repository,
+it also hosts other repositories such as those for the CPython developer
+guide and for Python Enhancement Proposals, along with various "sandbox"
+repositories for core developer experimentation.
+
+These supporting repositories could benefit greatly from user the simple
+"pull request" style workflow made popular by code hosting sites like
+GitHub and BitBucket.
+
+This PEP proposes introducing a more sophisticated approach to repository
+management that includes more "self service" features, including support
+for pull requests.
+
+
Current Tools
=============
@@ -162,23 +186,66 @@
* Rietveld (also hosted on bugs.python.org) for code review
* Buildbot (buildbot.python.org) for automated testing
-This proposal does *not* suggest replacing any of these tools, although
-implementing it effectively may require modifications to some or all of
-them.
+This proposal does *not* currently suggest replacing any of these tools,
+although implementing it effectively may require modifications to some or
+all of them.
It does however suggest the addition of new tools in order to automate
-additional parts of the workflow.
+additional parts of the workflow, as well as a critical review of these
+tools to see which, if any, may be candidates for replacement.
Proposal
========
-The essence of this proposal is that CPython aim to adopt a "core reviewer"
-development model, similar to that used by the OpenStack project.
+This proposal consists of two key components:
-These problems experienced by CPython are not unique. The OpenStack
-infrastructure team have come up with a well designed automated workflow
-that is designed to ensure:
+* Introducing RhodeCode for improved repository management
+* Introducing automated merge gating for the CPython project
+
+
+Improved repository management
+------------------------------
+
+The rise of free source code hosting sites like GitHub and BitBucket with a
+focus on improving the user experience have increased user expectations
+for the web based interface offered for source code repositories. This
+includes features like dynamic control of user permissions for repository
+administrators, online editing for documentation updates and similar small
+fixes, easy cloning and branching, etc.
+
+While GitHub and BitBucket are proprietary solutions to this problem that
+cannot be self-hosted, RhodeCode_ is a popular primarily open source solution
+that offers similar features to the major free hosting sites, while also
+allowing installation on your own servers. RhodeCode is also implemented
+in Python, allowing us to preserve our current situation of having our
+workflow tools being almost entirely self-hosting.
+
+There's nothing too complicated with this part of the proposal: it is
+essentially just a suggestion to convert hg.python.org to being backed
+by a RhodeCode Enterprise instance hosted on PSF infrastructure.
+
+All of the functional parts of RhodeCode Enterprise are open source under
+the GPLv3 license. The "look & feel" components are licensed under a
+`business source license`_ that is free for up to 20 users, as well as for
+organisations that qualify for one of RhodeCode's exemption categories
+(in the case of ``hg.python.org``, the relevant category is "public open
+source project").
+
+.. _RhodeCode: https://rhodecode.com/
+.. _business source license: https://rhodecode.com/licenses
+
+
+Automated merge gating for CPython
+----------------------------------
+
+The essence of this part of the proposal is that CPython aim to adopt a
+"core reviewer" development model, similar to that used by the OpenStack
+project.
+
+The workflow problems experienced by the CPython core development team are
+not unique. The OpenStack infrastructure team have come up with a well
+designed automated workflow that is designed to ensure:
* once a patch has been reviewed, further developer involvement is needed
only if the automated tests fail prior to merging
@@ -187,27 +254,35 @@
* the main development branch always stays green. Patches that do not pass
the automated tests do not get merged.
+If a core developer wants to tweak a patch prior to merging, they download
+it from the review tool, modify and *upload it back to the review tool*
+rather than pushing it directly to the source code repository.
+
The core of this workflow is implemented using a tool called Zuul_, a
Python web service created specifically for the OpenStack project, but
deliberately designed with a plugin based trigger and action system to make
it easier to adapt to alternate code review systems, issue trackers and
CI systems. James Blair of the OpenStack infrastructure team provided
an `excellent overview of Zuul
-<https://www.youtube.com/watch?v=xTPILCPRGeg>`__ at linux.conf.au 2014.
+<https://www.youtube.com/watch?v=sLD9LHc1QFM>`__ at linux.conf.au 2014.
While Zuul handles several workflows for OpenStack, the specific one of
interest for this PEP is the "merge gating" workflow.
For this workflow, Zuul is configured to monitor the Gerrit code review
-system for patches which have been marked as "+2 Approved". Once it sees
+system for patches which have been marked as "Approved". Once it sees
such a patch, Zuul takes it, and combines it into a queue of "candidate
merges". It then creates a pipeline of test runs that execute in parallel in
Jenkins (in order to allow more than 24 commits a day when a full test run
takes the better part of an hour), and are merged as they pass (and as all
the candidate merges ahead of them in the queue pass). If a patch fails the
-tests, Zuul takes it of the queue, cancels any test runs after that patch in
+tests, Zuul takes it out of the queue, cancels any test runs after that patch in
the queue, and rebuilds the queue without the failing patch.
+If a developer looks at a test which failed on merge and determines that it
+was due to an intermittent failure, then they can resubmit the patch for
+another attempt at merging.
+
To adapt this process to CPython, it should be feasible to have Zuul monitor
Rietveld for approved patches (which would require a feature addition in
Rietveld), submit them to Buildbot for testing on the stable buildbots, and
@@ -225,7 +300,7 @@
directly address several of the issues described in the Rationale above.
.. _Zuul: http://ci.openstack.org/zuul/
-.. _Elastic recheck: http://status.openstack.org/elastic-recheck/
+.. _Elastic recheck: http://status.openstack.org/elastic-recheck/>
Deferred Proposals
@@ -246,9 +321,9 @@
Infrastructure team), I don't see them as offering quite the same kind of
fundamental workflow improvement that merge gating appears to provide.
-However, it may be that the last is needed to handle intermittent test
-failures in the gate effectively, in which case it may need to be
-considered as a possible part of the initial deployment.
+However, if we find we are having too many problems with intermittent test
+failures in the gate, then introducing the "Elastic recheck" feature may
+need to be considered as part of the initial deployment.
Suggested Variants
@@ -269,10 +344,38 @@
deployment proves to have more trouble with test reliability than is
anticipated.
+It would also be possible to tweak the merge gating criteria such that it doesn't
+run the test suite if it detects that the patch hasn't modified any files
+outside the "Docs" tree, and instead only checks that the documentation
+builds without errors.
+
+As yet another alternative, it may be reasonable to move some parts of the
+documentation (such as the tutorial) out of the main source repository and
+manage them using the simpler pull request based model.
+
Perceived Benefits
==================
+Improved repository management
+------------------------------
+
+The primary benefit of using RhodeCode to manage hg.python.org is that
+supporting repositories such as the developer guide and the PEP repo could
+now be managed using pull requests and online editing. This would be
+much simpler then the current workflow which requires PEP editors and
+other core developers to act as intermediaries to apply updates suggested
+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.
+
+
+Automated merge gating for CPython
+----------------------------------
+
The benefits of this proposal accrue most directly to the core development
team. First and foremost, it means that once we mark a patch as "Approved"
in the updated code review system, *we're usually done*. The extra 20-30
@@ -292,7 +395,7 @@
However, removing this time sink from the core development team should also
improve the experience of CPython development for other contributors, as it
-removes several of the opportunities for patches to get "dropped on the
+eliminates several of the opportunities for patches to get "dropped on the
floor", as well as increasing the time core developers are likely to have
available for reviewing contributed patches.
@@ -324,6 +427,25 @@
Zuul trigger and action plugins, and may require additional development
in some of our existing tools.
+RhodeCode may also require some adjustment to fit in with existing
+infrastructure.
+
+
+User account management
+-----------------------
+
+Ideally, RhodeCode's user account management would be integrated with
+the existing account management in Roundup.
+
+
+Preserving existing SSH access and links for Mercurial repositories
+-------------------------------------------------------------------
+
+Adopting RhodeCode may result in some changes to where repositories are
+located on the hg.python.org filesystem. We may want to ensure that
+existing links into the hg.python.org web service are preserved, and should
+definitely ensure that existing SSH based clones continue to work correctly.
+
Rietveld/Roundup vs Gerrit
--------------------------
@@ -379,6 +501,9 @@
such that the hg-git plugin appears to be the most mature of the available
options for hg-git interoperability).
+One advantage of adopting RhodeCode to manage the repository infrastructure
+is that it supports git repositories in addition to Mercurial repositories.
+
Buildbot vs Jenkins
-------------------
@@ -435,15 +560,24 @@
queue. This would just require a change in Rietveld to indicate which
branch was the intended target of the patch.
-The Python 3.x maintenance branches are potentially more complicated. One
-option would be to simply stop using Mercurial merges to manage them, and
-instead treat them as independent heads, similar to the Python 2.7 branch.
-Patches that applied cleanly to both the active maintenance branch and to
-default would then just be submitted to both queues, while other changes
-might involve submitting separate patches for the active maintenance branch
-and for default. This approach also has the benefit of adjusting cleanly to
-the intermittent periods where we have two active Python 3 maintenance
-branches.
+The Python 3.x maintenance branches are potentially more complicated. My
+current recommendation is to simply stop using Mercurial merges to manage
+them, and instead treat them as independent heads, similar to the Python
+2.7 branch. Patches that apply cleanly to both the active maintenance branch
+and to default would then just be submitted to both queues, while other
+changes might involve submitting separate patches for the active maintenance
+branch and for default. This approach also has the benefit of adjusting
+cleanly to the intermittent periods where we have two active Python 3
+maintenance branches.
+
+This does suggest some user interface ideas for the branch nomination
+interface for a patch:
+
+* default to "default" on issues that are marked as "enhancement"
+* default to "3.x+" (where 3.x is the oldest branch in regular maintenance)
+ on any other issues
+* also offer the ability to select specific branches in addition to or
+ instead of the default selection
Handling of security branches
@@ -451,13 +585,13 @@
For simplicity's sake, I would suggest leaving the handling of
security-fix only branches alone: the release managers for those branches
-backport specific changes manually.
+would continue to backport specific changes manually.
Handling of NEWS file updates
-----------------------------
-Our current approaching to handling NEWS file updates regularly results in
+Our current approach to handling NEWS file updates regularly results in
spurious conflicts when merging bug fixes forward from an active maintenance
branch to a later branch.
@@ -547,12 +681,87 @@
more automated preparation of release artefacts as well.
+Practical Challenges
+====================
+
+The PSF runs its own directly and indirectly sponsored workflow
+infrastructure primarily due to past experience with unacceptably poor
+performance and inflexibility of infrastructure provided for free to the
+general public. CPython development was originally hosted on SourceForge,
+with source control moved to self hosting when SF was both slow to offer
+Subversion support and suffering from CVS performance issues (see PEP 347),
+while issue tracking later moved to the open source Roundup issue tracker
+on dedicated sponsored hosting (from Upfront Systems), due to a combination
+of both SF performance issues and general usability issues with the SF
+tracker at the time (the outcome and process for the new tracker selection
+were captured on the `python.org wiki
+<https://wiki.python.org/moin/CallForTrackers>`__ rather than in a PEP).
+
+Accordingly, proposals that involve setting ourselves up for "SourceForge
+usability and reliability issues, round two" aren't likely to gain any
+traction with either the CPython core development team or with the PSF
+Infrastructure committee. This proposal respects that history by
+recommending only tools that are available for self-hosting as sponsored
+or PSF funded infrastructure, and are also open source Python projects that
+can be customised to meet the needs of the CPython core development team.
+
+However, for this proposal to be a success (if it is accepted), we need to
+understand how we are going to carry out the necessary configuration,
+customisation, integration and deployment work.
+
+The last attempt at adding a new piece to the CPython support infrastructure
+(speed.python.org) has unfortunately foundered due to the lack of time to
+drive the project from the core developers and PSF board members involved,
+and the difficulties of trying to bring someone else up to speed to lead
+the activity (the hardware donated to that project by HP is currently in
+use to support PyPy instead, but the situation highlights some
+of the challenges of relying on volunteer labour with many other higher
+priority demands on their time to steer projects to completion).
+
+Even ultimately successful past projects, such as the source control
+migrations from CVS to Subversion and from Subversion to Mercurial, the
+issue tracker migration from SourceForge to Roundup, the code review
+integration between Roundup and Rietveld and the introduction of the
+Buildbot continuous integration fleet, have taken an extended period of
+time as volunteers worked their way through the many technical and social
+challenges involved.
+
+Accordingly, one possible outcome of this proposal may be a recommendation
+to the PSF to investigate how to sustain direct investment in ongoing paid
+development on CPython workflow tools, similar to the ongoing funded
+development that supports the continuous integration infrastructure for
+OpenStack. Some possible approaches include:
+
+* the PSF funding part-time or contract based development on CPython workflow
+ tools, either on an ad hoc basic through the existing grants program, or
+ on a more permanent basis, collaborating with the CPython core development
+ team to determine the scope of the desired improvements.
+* discussing a possible partnership with the OpenStack Foundation to
+ collaborate on shared tool development that ultimately benefits both
+ organisations (for example, the OpenStack infrastructure team aren't
+ especially happy with the maintainability challenges posed by Gerrit, so
+ improvements to Rietveld to make it a viable candidate for replacing
+ Gerrit may be something they would be interested in).
+* PSF (and OpenStack) sponsor members allocating part-time or full-time
+ staff to work on improving the CPython workflow tools, similar to the way
+ such staff are allocated to improving OpenStack workflow tools.
+
+Note that this model of directing paid development efforts at improving the
+tools that support the contributions of volunteers is also one of the
+known ways to incorporate funded development into a primarily volunteer
+driven project without creating resentment between unpaid and paid
+contributors: it's harder to resent people that are being paid specifically
+to make the tools, workflow and general experience more pleasant for the
+unpaid contributors.
+
+
Open Questions
==============
-Pretty much everything in the PEP. Do we want to do this? Is Rietveld the
-right place to hook Zuul into our current workflows? How do we want to
-address the various technical challenges?
+Pretty much everything in the PEP. Do we want to adopt RhodeCode? Do we
+want to adopt merge gating and Zuul? Is Rietveld the right place to hook
+Zuul into our current workflows? How do we want to address the various
+technical challenges?
Assuming we do want to do it (or something like it), how is the work going
to get done? Do we try to get it done solely as a volunteer effort? Do we
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list