[Python-Dev] My thinking about the development process (original) (raw)

Donald Stufft donald at stufft.io
Sat Dec 6 02:39:10 CET 2014

On Dec 5, 2014, at 8:26 PM, R. David Murray <rdmurray at bitdance.com> wrote:

On Fri, 05 Dec 2014 15:17:35 -0700, Eric Snow <ericsnowcurrently at gmail.com> wrote: On Fri, Dec 5, 2014 at 1:04 PM, Brett Cannon <bcannon at gmail.com> wrote:

We don't exactly have a ton of people constantly going "I'm so bored because everything for Python's development infrastructure gets sorted so quickly!" A perfect example is that R. David Murray came up with a nice update for our workflow after PyCon but then ran out of time after mostly defining it and nothing ever became of it (maybe we can rectify that at PyCon?). Eric Snow has pointed out how he has written similar code for pulling PRs from I think GitHub to another code review tool, but that doesn't magically make it work in our infrastructure or get someone to write it and help maintain it (no offense, Eric).

None taken. I was thinking the same thing when I wrote that. :)

IOW our infrastructure can do anything, but it can't run on hopes and dreams. Commitments from many people to making this happen by a certain deadline will be needed so as to not allow it to drag on forever. People would also have to commit to continued maintenance to make this viable long-term. The biggest blocker to my actually working the proposal I made was that people wanted to see it in action first, which means I needed to spin up a test instance of the tracker and do the work there. That barrier to getting started was enough to keep me from getting started...even though the barrier isn't that high (I've done it before, and it is easier now than it was when I first did it), it is still a lot higher than checking out CPython and working on a patch. That's probably the biggest issue with anyone contributing to tracker maintenance, and if we could solve that, I think we could get more people interested in helping maintain it. We need the equivalent of dev-in-a-box for setting up for testing proposed changes to bugs.python.org, but including some standard way to get it deployed so others can look at a live system running the change in order to review the patch. Maybe our infrastructure folks will have a thought or two about this? I'm willing to put some work into this if we can figure out what direction to head in. It could well be tied in to moving bugs.python.org in with the rest of our infrastructure, something I know Donald has been noodling with off and on; and I'm willing to help with that as well.

Theoretically you could create a dev environment with the psf-salt stuff once it’s actually done. It won’t be the most efficient use of your computer resources because it’d expect to run several vagrant VMs locally but it would also match “production” (in a salt-ified world) better. It wouldn’t be as good as a dedicated dev setup for it, but it would probably be better than a sort of “yea here’s a bunch of steps that sort of get you close YOLO”.

It sounds like being able to propose and test changes to our Roundup instance (and test other services talking to Roundup, before deploying them for real) is going to be critical to improving our workflow no matter what other decisions are made, so we need to make it easier to do. In other words, it seems like the key to improving the productivity of our CPython patch workflow is to improve the productivity of the patch workflow for our key workflow resource, bugs.python.org. --David

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

More information about the Python-Dev mailing list