On 23 Nov 2014 18:11, "Donald Stufft" <don...@stufft.io> wrote: > > On Nov 23, 2014, at 2:35 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > > > In the absence of a proposal to change version control systems > > (again), the lack of Mercurial hosting on GitHub makes it rather a > > moot point. Given that we can barely muster up any enthusiasm for > > rehosting *without* changing version control systems (and the number > > of CI systems that integrate with hg.python.org repos other than the > > main CPython one is exactly zero), any proposal that involves doing > > even *more* work seems doubly doomed. > > > > I’d volunteer to do the work to get the PEPs, and possibly other repositories > onto Github if we so decided to do so. Don’t let the lack of volunteer stop > that because I will find the time to do it if need be.
It's the other way around: someone would have to volunteer to make the case that switching version control systems will actually help in any way whatsoever with the core reviewer bandwidth problem. We do *not* have a shortage of people wanting to contribute. While ongoing outreach efforts are essential to promote increased diversity in the contributor base and to counter natural attrition, there is currently no major problem that needs solving on that front. CPython is high profile enough that folks are willing to do battle with the current complicated contribution process, so we're already one of the most active open source projects in the world, in *spite* of the problems with the existing workflow. This high level of activity also takes place in spite of the fact that direct corporate investment in paid contributions to the CPython runtime currently don't really reflect the key role that CPython holds in the enterprise Linux, OpenStack, data analysis, and education ecosystems (to name a few where I personally have some level of involvement either personally or through work). Where I believe we *do* have a problem is with failing to make the best possible use of core developer contribution time, as typos and other minor fixes to project (rather than product) documentation are managed through the same offline patch & upload process as the reference interpreter itself. (There are other issues as well, but they're out of scope for the current discussion, which is about the support repos, rather than CPython - the same problem exists there, but the solution is unlikely to be as straightforward). Patches getting held up in the review queue for weeks or months is a *huge* barrier to contribution, as it prevents the formation of the positive feedback cycle where having a contribution accepted feels good, so folks are more likely to want to contribute again. In that context, the useful features that a richer repo hosting application can potentially offer are single-click acceptance and merging of documentation changes that aren't directly linked to a specific CPython version, as well as the ability to make trivial fixes to that documentation (like fixing a typo) entirely online. Those features are readily accessible without changing the underlying version control system (whether self-hosted through Kallithea or externally hosted through BitBucket or RhodeCode). Thus the folks that want to change the version control system need to make the case that doing so will provide additional benefits that *can't* be obtained in a less disruptive way. >From my perspective, swapping out Mercurial for git achieves exactly nothing in terms of alleviating the review bottleneck (since the core developers that strongly prefer the git UI will already be using an adapter), and is in fact likely to make it worse by putting the greatest burden in adapting to the change on the folks that are already under the greatest time pressure. It's also worth keeping in mind that changing the underlying VCS means changing *all* the automation scripts, rather than just updating the configuration settings to reflect a new hosting URL. Orchestrating this kind of infrastructure enhancement for Red Hat *is* my day job, and you almost always want to go for the lowest impact, lowest risk approach that will alleviate the bottleneck you're worried about while changing the smallest possible number of elements in the overall workflow management system. That underlying calculation doesn't really change much even when the units shift from budget dollars to volunteers' time and energy. 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/archive%40mail-archive.com
