<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 22, 2014, at 9:59 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""><br class="">
On 22 Nov 2014 07:37, "Donald Stufft" <<a href="mailto:donald@stufft.io" class="">donald@stufft.io</a>> wrote:<br class="">
> > On Nov 21, 2014, at 3:59 PM, Ned Deily <<a href="mailto:nad@acm.org" class="">nad@acm.org</a>> wrote:<br class="">
> > Sure, I get that. But we're not even talking here about the main Python<br class="">
> > docs since they are part of the CPython repos, only ancillary repos like<br class="">
> > PEPs and the developer's guide. The level of activity on those is quite<br class="">
> > small. So, thinking about it a bit more, PEPs don't normally have bug<br class="">
> > tracker issues associated with them so I suppose my concerns about issue<br class="">
> > tracker aren't a major concern for them. The dev guide does get issues<br class="">
> > opened about it and I suppose they could be managed. But, without<br class="">
> > tackling the CPython repo workflow (a *much* bigger deal), is the<br class="">
> > divergence in workflows worth it? I dunno.</p><p dir="ltr" class="">I also think the tutorial and howto guides should be broken out of the main CPython repo & made version independent (with internal version specific notes).</p><p dir="ltr" class="">That offers no compelling advantages right now, but becomes far more beneficial if it comes with a switch to enabling online editing.</p><p dir="ltr" class="">> Yea for the smaller repositories I don’t have a whole lot of opinion<br class="">
> about if the benefit buys us much, especially since one of the goals<br class="">
> is new-person friendliness but the problem is that it doesn’t translate<br class="">
> to contributing to CPython itself.</p><p dir="ltr" class="">OK, different question. Has anyone here actually even *read* the workflow PEPs I wrote? They were on the agenda for the language summit, but got bumped due to lack of time (which I'm still annoyed about, given the comparatively inconsequential things that chewed up a whole lot of the day).</p><p dir="ltr" class="">I've only had a couple of folks from outside the core dev community express interest in them. Personally, the lack of online editing support annoys me immensely whenever I need to work on PEPs or the devguide. I also think it's ridiculous that we have dozens (hundreds?) of folks running community workshops, and all creating their own custom documentation, rather than us finding a way to better enable their collaboration on the official tutorial.</p><p dir="ltr" class="">The BitBucket proposal in this thread came out of a desire to avoid adding yet more work to an understaffed group of primarily volunteers maintaining the infrastructure (the paid admins are more focused on incident response and general infrastructure support, rather than spinning up new workflow services).</p><p dir="ltr" class="">My preferred answer remains setting up a srlf-hosted <a href="http://forge.python.org/" class="">forge.python.org</a>, but I've seen little evidence we have the capacity to deploy & maintain such a service effectively, given the relative lack of interest shown in the idea by almost everyone I've spoken to about it. Any progress has only come with a lot of pushing from me, and I just don't have the personal bandwidth to sustain that at this point. That's why the related PEPs were deferred, and the only responses I've received regarding potentially taking them over have come from folks outside the core development community, which really doesn't help very much in removing my availability as a bottleneck in the workflow improvement process.</p><p dir="ltr" class="">If nobody wants to maintain a self-hosted forge, or even enable the folks that have expressed interest in setting it up & maintaining it, then the right answer is "don't do it" - we should use a commercial service instead.</p><div class=""><br class=""></div></div></blockquote><br class=""></div><div><div><div>I think I told you before, but if not I’ll say it now :)</div><div><br class=""></div><div>From the infrastructure side spinning up a new VM is pretty easy, what we need</div><div>is someone to write some salt states in the psf-salt repository that will</div><div>deploy an instance of whatever software. I don't have time to figure out the</div><div>intracities of the various software and deploy them but I can help with</div><div>figuring out our infra layout. The other thing the infrastructure side would</div><div>need is some guidance on what size/flavor of Rackspace VM it needs and what</div><div>additional services it would need (we have a PostgreSQL database already, does</div><div>it need extra disk space? A Queue? Object Store?). There is a more or less</div><div>working vagrant setup in the psf-salt[1] repository (a few of the roles don't</div><div>work yet without manual configuration, like the hg role) but for what someone</div><div>would need for setting up a new service it should all be there.</div><div><br class=""></div><div>I'm not sure what else we can do to enable someone who *does* want to work on</div><div>it to be able to set it up. However I'm not against using a commerical service</div><div>for smaller repositories. It's fine with me, I don't have a big opinion one</div><div>way or the other other than I greatly prefer Github over Bitbucket.</div><div><br class=""></div><div>[1] <a href="https://github.com/python/psf-salt" class="">https://github.com/python/psf-salt</a></div></div></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>