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

R. David Murray rdmurray at bitdance.com
Sat Dec 6 02:26:08 CET 2014

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.

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

More information about the Python-Dev mailing list