> On Nov 22, 2014, at 9:59 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > On 22 Nov 2014 07:37, "Donald Stufft" <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > > > On Nov 21, 2014, at 3:59 PM, Ned Deily <n...@acm.org > > > <mailto:n...@acm.org>> wrote: > > > Sure, I get that. But we're not even talking here about the main Python > > > docs since they are part of the CPython repos, only ancillary repos like > > > PEPs and the developer's guide. The level of activity on those is quite > > > small. So, thinking about it a bit more, PEPs don't normally have bug > > > tracker issues associated with them so I suppose my concerns about issue > > > tracker aren't a major concern for them. The dev guide does get issues > > > opened about it and I suppose they could be managed. But, without > > > tackling the CPython repo workflow (a *much* bigger deal), is the > > > divergence in workflows worth it? I dunno. > > 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). > > That offers no compelling advantages right now, but becomes far more > beneficial if it comes with a switch to enabling online editing. > > > Yea for the smaller repositories I don’t have a whole lot of opinion > > about if the benefit buys us much, especially since one of the goals > > is new-person friendliness but the problem is that it doesn’t translate > > to contributing to CPython itself. > > 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). > > 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. > > 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). > > My preferred answer remains setting up a srlf-hosted forge.python.org > <http://forge.python.org/>, 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. > > 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. > >
I think I told you before, but if not I’ll say it now :) From the infrastructure side spinning up a new VM is pretty easy, what we need is someone to write some salt states in the psf-salt repository that will deploy an instance of whatever software. I don't have time to figure out the intracities of the various software and deploy them but I can help with figuring out our infra layout. The other thing the infrastructure side would need is some guidance on what size/flavor of Rackspace VM it needs and what additional services it would need (we have a PostgreSQL database already, does it need extra disk space? A Queue? Object Store?). There is a more or less working vagrant setup in the psf-salt[1] repository (a few of the roles don't work yet without manual configuration, like the hg role) but for what someone would need for setting up a new service it should all be there. I'm not sure what else we can do to enable someone who *does* want to work on it to be able to set it up. However I'm not against using a commerical service for smaller repositories. It's fine with me, I don't have a big opinion one way or the other other than I greatly prefer Github over Bitbucket. [1] https://github.com/python/psf-salt --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ 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
