diff --git a/pep-0462.txt b/pep-0462.txt index 4b97bce38..1ad00359c 100644 --- a/pep-0462.txt +++ b/pep-0462.txt @@ -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 `__ 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? diff --git a/pep-0474.txt b/pep-0474.txt index 5815c548b..66d1b0e02 100644 --- a/pep-0474.txt +++ b/pep-0474.txt @@ -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 `__ 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 =================================