(original) (raw)

On Fri, 05 Dec 2014 15:17:35 -0700, Eric Snow <ericsnowcurrently@gmail.com> wrote:

> On Fri, Dec 5, 2014 at 1:04 PM, Brett Cannon <bcannon@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.