On Sat Nov 22 2014 at 10:00:03 AM Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 22 Nov 2014 07:37, "Donald Stufft" <don...@stufft.io> wrote: > > > On Nov 21, 2014, at 3:59 PM, Ned Deily <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 did and was looking forward to them coming to fruition. > 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, > 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. > There are two goals to any improvement to the development workflow: that which helps the core devs and that which helps everyone else. For helping core devs that's getting some CI set up which will test every patch submitted, single-click patch committal from the issue tracker, etc. For everyone else it's inline editing and whatever it takes to get patches accepted faster (I know Nick is pointing out he wants inline editing for PEPs and docs but I don't view that as critical for core devs who already have the checkouts available and have the workflow memorized). >From my perspective, getting our commit workflow improved is the critical first step before we worry about making it easier to receive patches. If we can't keep up with an influx of patches that might occur from inline editing then there is little point in having it; frustrating people that we can't commit patches as fast as we receive them is not helpful. Now in terms of how the heck we are ever going to improve our workflow, that's tricky. As Nick as pointed out we are low on volunteer time. Take the issue tracker as an example: Ezio Melotti does a large amount of work and R. David Murray also helps, but that's mostly it (Martin von Löwis has helped in the past but has been mostly absent as of late). We are not well covered in the "hit by a bus" scenario. I understand the viewpoint of not wanting to give up control of our process to a third party, and I understand not wanting to use closed-source software. But at some point there is a "practicality beats purity" line we have to either cross to improve our workflow as we simply don't have the software or volunteers to improve our process or we stay as-is and accept our contribution rate will be lower than it could be due to self-imposed barriers to entry for contributors and review overhead for core developers. I see two solutions moving forward. One is to take some bit of documentation, put it up on bitbucket or GitHub and tell people to contribute there as an experiment and some set of core devs can volunteer to accept pull requests over there. Every so often someone can sync up that documentation with the default hg repo and see what that does to contribution rates and patch acceptance turn-around. The tutorial is probably a good one since that's going to be where beginners might want to contribute, it doesn't have a high churn rate, and it's easy to tell people teaching Python to ask for contributions on GitHub or bitbucket to those who may want to contribute. The other solution is to let people fork our GitHub and bitbucket mirrors, let people develop their patch on those services, and then in the issue tracker let them submit the link to their fork. We can then have a Python script for us -- either in Tools/ or built into the issue tracker -- which can take their fork, download the diff, apply it, and then we can follow our normal review workflow (we honestly could probably stand to have a script like this now so that all you need to know is the issue # to download and apply a patch; also having people submit links from other services is we get to use their visual diff tools). This approach has the perk that we still control the infrastructure and workflow, but it also lets people use these other platform's facilities for inline editing, etc. We could even get something like Travis set up so that we can even get free CI for patches (although I think Travis only triggers on PRs so we may need to ask people to send PRs that we actually never accept just to trigger the process). The point is that we could "grease the wheels" between our infrastructure and that of GitHub and bitbucket to make getting contributions from those platforms easier for both contributors through simpler tooling and us through potential free CI and visual diffs on the other platforms. Do either of these approaches sound reasonable to people? -Brett > Regards, > Nick. > > > > > --- > > 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/ncoghlan%40gmail.com > _______________________________________________ > 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/ > brett%40python.org >
_______________________________________________ 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
