[Python-checkins] peps: Workflow automation proposal updates

[nick.coghlan]

http://hg.python.org/peps/rev/bb1aa7f8efdc
changeset:   5398:bb1aa7f8efdc
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Tue Mar 04 21:15:03 2014 +1000
summary:
  Workflow automation proposal updates

- merge gating makes it easier for others to do continuous
  integration against the CPython development branches
- interesting IRC chat with the CTO of RhodeCode last week,
  updated accordingly

files:
  pep-0462.txt |  36 ++++++++++++++++++++++++++++++++----
  1 files changed, 32 insertions(+), 4 deletions(-)


diff --git a/pep-0462.txt b/pep-0462.txt
--- a/pep-0462.txt
+++ b/pep-0462.txt
@@ -232,6 +232,9 @@
 (in the case of ``hg.python.org``, the relevant category is "public open
 source project").
 
+The RhodeCode developers have also expressed interest in helping out with
+ensuring a python.org RhodeCode deployment is successful.
+
 .. _RhodeCode: https://rhodecode.com/
 .. _business source license: https://rhodecode.com/licenses
 
@@ -411,13 +414,21 @@
 the other sprint participants than it is on things that are sufficiently
 mechanical that a computer can (and should) handle them.
 
-Finally, with most of the ways to make a mistake when committing a change
-automated out of existence, there are substantially fewer new things to
+With most of the ways to make a mistake when committing a change
+automated out of existence, there are also substantially fewer new things to
 learn when a contributor is nominated to become a core developer. This
 should have a dual benefit, both in making the existing core developers more
 comfortable with granting that additional level of responsibility, and in
 making new contributors more comfortable with exercising it.
 
+Finally, a more stable default branch in CPython makes it easier for
+other Python projects to conduct continuous integration directly against the
+main repo, rather than having to wait until we get into the release
+candidate phase. At the moment, setting up such a system isn't particularly
+attractive, as it would need to include an additional mechanism to wait
+until CPython's own Buildbot fleet had indicate that the build was in a
+usable state.
+
 
 Technical Challenges
 ====================
@@ -434,8 +445,18 @@
 User account management
 -----------------------
 
-Ideally, RhodeCode's user account management would be integrated with
-the existing account management in Roundup.
+Ideally we'd be able to offer a single account that spans all python.org
+services, including RhodeCode, Roundup/Rietveld, PyPI and the back end for
+the new python.org site, but actually implementing that would be a distinct
+infrastructure project, independent of this PEP.
+
+A potentially simpler near term solution would be if RhodeCode's user
+account management could be integrated with the existing account management
+in Roundup, similar to what was done for Rietveld. However, if that also
+turns out to be impractical in the near term, we would merely end up with
+another identity silo to be integrated at a later date, suggesting that
+this doesn't need to be considered a blocker for an initial RhodeCode
+deployment.
 
 
 Preserving existing SSH access and links for Mercurial repositories
@@ -784,6 +805,9 @@
 workflow changes are not expected to require any significant changes in
 Roundup or Buildbot).
 
+Unfortunately, the lead RhodeCode developers aren't able to attend PyCon US
+this year, or we would have invited them, too.
+
 
 Acknowledgements
 ================
@@ -793,6 +817,10 @@
 Taylor for additional technical feedback following publication of the
 initial draft.
 
+Thanks also to Marcin Kuzminski (CTO of RhodeCode) for getting in touch to
+express their interest in helping to ensure the success of a RhodeCode
+deployment if we choose to proceed down that path.
+
 
 Copyright
 =========

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