[Python-Dev] My thinking about the development process

[Donald Stufft]

> 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