iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update Kallithea PEPs with change to my availability

This commit is contained in:
Nick Coghlan 2015-02-09 19:03:43 +10:00
parent 1641c51ddd
commit b6fa3e2e91
2 changed files with 39 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
pep-0462.txt
View File

@ -337,7 +337,7 @@ developer present (such as the sprints at PyCon AU for the last
few years), the merge queue would allow that developer to focus more of
their time on reviewing patches and helping the other contributors at the
sprint, since accepting a patch for inclusion would now be a single click
in the Rietveld UI, rather than the relatively time consuming process that
in the Kallithea UI, rather than the relatively time consuming process that
it is currently. Even when multiple core developers are present, it is
better to enable them to spend their time and effort on interacting with
the other sprint participants than it is on things that are sufficiently
@ -381,13 +381,6 @@ indicating whether or not the uploader of a patch has signed a PSF
Contributor Licensing Agreement, which may require further development to
link contributor accounts between the Kallithea instance and Roundup.
We would likely also want to improve the existing patch handling,
in particular looking at how the Roundup/Reitveld integration handles cases
where it can't figure out a suitable base version to use when generating
the review (if Rietveld gains the ability to nominate a particular target
repository and branch for a patch, then this may be relatively easy to
resolve).
Some of the existing Zuul triggers work by monitoring for particular comments
(in particular, recheck/reverify comments to ask Zuul to try merging a
change again if it was previously rejected due to an unrelated intermittent
@ -636,33 +629,21 @@ 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:
Fortunately, as several aspects of this proposal and PEP 474 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.
* 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.
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.
Open Questions
@ -673,18 +654,14 @@ Zuul? How do we want to address the various technical challenges?
Are the Kallithea and Zuul development communities open to the kind
of collaboration that would be needed to make this effort a success?
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
put together a grant proposal for the PSF board to consider (assuming we can
find people willing and available to do the work)?
Do we approach the OpenStack Foundation for assistance, since
While I've arranged to spend some of my own work time on this, do we want to
approach the OpenStack Foundation for additional assistance, since
we're a key dependency of OpenStack itself, Zuul is a creation of the
OpenStack infrastructure team, and the available development resources for
OpenStack currently dwarf those for CPython?
Do those of us working for Python redistributors and major users (including
me), attempt to make the business case to our superiors for investing
Are other interested folks working for Python redistributors and major users
also in a position to make a business case to their superiors for investing
developer time in supporting this effort?

20
pep-0474.txt
View File

@ -203,6 +203,26 @@ 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.
Technical Concerns and Challenges
=================================