[Python-Dev] My thinking about the development process

[R. David Murray]

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