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 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 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 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 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 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 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 Contributor Licensing Agreement, which may require further development to
link contributor accounts between the Kallithea instance and Roundup. 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 Some of the existing Zuul triggers work by monitoring for particular comments
(in particular, recheck/reverify comments to ask Zuul to try merging a (in particular, recheck/reverify comments to ask Zuul to try merging a
change again if it was previously rejected due to an unrelated intermittent 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 time as volunteers worked their way through the many technical and social
challenges involved. challenges involved.
Accordingly, one possible outcome of this proposal may be a recommendation Fortunately, as several aspects of this proposal and PEP 474 align with
to the PSF to investigate how to sustain direct investment in ongoing paid various workflow improvements under consideration for Red Hat's
development on CPython workflow tools, similar to the ongoing funded `Beaker <https://beaker-project.org>`__ open source hardware integration
development that supports the continuous integration infrastructure for testing system and other work-related projects, I have arranged to be able
OpenStack. Some possible approaches include: to devote ~1 day a week to working on CPython infrastructure projects.
* the PSF funding part-time or contract based development on CPython workflow Together with Rackspace's existing contributions to maintaining the
tools, either on an ad hoc basic through the existing grants program, or pypi.python.org infrastructure, I personally believe this arrangement is
on a more permanent basis, collaborating with the CPython core development indicative of a more general recognition amongst CPython redistributors and
team to determine the scope of the desired improvements. major users of the merit in helping to sustain upstream infrastructure
* discussing a possible partnership with the OpenStack Foundation to through direct contributions of developer time, rather than expecting
collaborate on shared tool development that ultimately benefits both volunteer contributors to maintain that infrastructure entirely in their
organisations (for example, the OpenStack infrastructure team aren't spare time or funding it indirectly through the PSF (with the additional
especially happy with the maintainability challenges posed by Gerrit, so management overhead that would entail). I consider this a positive trend, and
improvements to Rietveld to make it a viable candidate for replacing one that I will continue to encourage as best I can.
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 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 Are the Kallithea and Zuul development communities open to the kind
of collaboration that would be needed to make this effort a success? 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 While I've arranged to spend some of my own work time on this, do we want to
to get done? Do we try to get it done solely as a volunteer effort? Do we approach the OpenStack Foundation for additional assistance, since
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
we're a key dependency of OpenStack itself, Zuul is a creation of the we're a key dependency of OpenStack itself, Zuul is a creation of the
OpenStack infrastructure team, and the available development resources for OpenStack infrastructure team, and the available development resources for
OpenStack currently dwarf those for CPython? OpenStack currently dwarf those for CPython?
Do those of us working for Python redistributors and major users (including Are other interested folks working for Python redistributors and major users
me), attempt to make the business case to our superiors for investing also in a position to make a business case to their superiors for investing
developer time in supporting this effort? 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. 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 Technical Concerns and Challenges
================================= =================================