[Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

On 23 Nov 2014 18:11, "Donald Stufft" <donald at stufft.io> wrote:
> > On Nov 23, 2014, at 2:35 AM, Nick Coghlan <ncoghlan at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141123/1d0f59e9/attachment.html>