<br><br><div class="gmail_quote">On Fri Dec 05 2014 at 8:31:27 PM R. David Murray <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 05 Dec 2014 15:17:35 -0700, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>> wrote:<br>
> On Fri, Dec 5, 2014 at 1:04 PM, Brett Cannon <<a href="mailto:bcannon@gmail.com" target="_blank">bcannon@gmail.com</a>> wrote:<br>
> > We don't exactly have a ton of people<br>
> > constantly going "I'm so bored because everything for Python's development<br>
> > infrastructure gets sorted so quickly!" A perfect example is that R. David<br>
> > Murray came up with a nice update for our workflow after PyCon but then ran<br>
> > out of time after mostly defining it and nothing ever became of it (maybe we<br>
> > can rectify that at PyCon?). Eric Snow has pointed out how he has written<br>
> > similar code for pulling PRs from I think GitHub to another code review<br>
> > tool, but that doesn't magically make it work in our infrastructure or get<br>
> > someone to write it and help maintain it (no offense, Eric).<br>
><br>
> None taken.  I was thinking the same thing when I wrote that. :)<br>
><br>
> ><br>
> > IOW our infrastructure can do anything, but it can't run on hopes and<br>
> > dreams. Commitments from many people to making this happen by a certain<br>
> > deadline will be needed so as to not allow it to drag on forever. People<br>
> > would also have to commit to continued maintenance to make this viable<br>
> > long-term.<br>
<br>
The biggest blocker to my actually working the proposal I made was that<br>
people wanted to see it in action first, which means I needed to spin up<br>
a test instance of the tracker and do the work there.  That barrier to<br>
getting started was enough to keep me from getting started...even though<br>
the barrier isn't *that* high (I've done it before, and it is easier now<br>
than it was when I first did it), it is still a *lot* higher than<br>
checking out CPython and working on a patch.<br>
<br>
That's probably the biggest issue with *anyone* contributing to tracker<br>
maintenance, and if we could solve that, I think we could get more<br>
people interested in helping maintain it.  We need the equivalent of<br>
dev-in-a-box for setting up for testing proposed changes to<br>
<a href="http://bugs.python.org" target="_blank">bugs.python.org</a>, but including some standard way to get it deployed so<br>
others can look at a live system running the change in order to review<br>
the patch.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe our infrastructure folks will have a thought or two about this?<br>
I'm willing to put some work into this if we can figure out what<br>
direction to head in.  It could well be tied in to moving<br>
<a href="http://bugs.python.org" target="_blank">bugs.python.org</a> in with the rest of our infrastructure, something I know<br>
Donald has been noodling with off and on; and I'm willing to help with<br>
that as well.<br>
<br>
It sounds like being able to propose and test changes to our Roundup<br>
instance (and test other services talking to Roundup, before deploying<br>
them for real) is going to be critical to improving our workflow no<br>
matter what other decisions are made, so we need to make it easier to<br>
do.<br>
<br>
In other words, it seems like the key to improving the productivity of<br>
our CPython patch workflow is to improve the productivity of the patch<br>
workflow for our key workflow resource, <a href="http://bugs.python.org" target="_blank">bugs.python.org</a>.<br></blockquote><div><br></div><div>Quite possible and since no one is suggesting we drop <a href="http://bugs.python.org">bugs.python.org</a> it's a worthy goal to have regardless of what PEP gets accepted.</div></div>