On Fri Dec 05 2014 at 8:31:27 PM R. David Murray <rdmur...@bitdance.com> wrote:
> On Fri, 05 Dec 2014 15:17:35 -0700, Eric Snow <ericsnowcurren...@gmail.com> > wrote: > > On Fri, Dec 5, 2014 at 1:04 PM, Brett Cannon <bcan...@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 it's just me and all the Docker/Rocket hoopla that's occurred over the past week, but this just screams "container" to me which would make getting a test instance set up dead simple. > > 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. > Quite possible and since no one is suggesting we drop bugs.python.org it's a worthy goal to have regardless of what PEP gets accepted.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
