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

[Donald Stufft]

> On Nov 23, 2014, at 1:49 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 23 November 2014 at 16:10, Guido van Rossum <guido at python.org> wrote:
>> On Saturday, November 22, 2014, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> The learning curve on git is still awful - it offers no compelling
>>> advantages over hg, and GitHub doesn't offer any huge benefits over
>>> BitBucket for Sphinx based documentation (ReadTheDocs works just as
>>> well with either service).
>> 
>> 
>> Git may well have a learning curve, but ever since I "got" it I started
>> preferring it over hg.
> 
> I took the git knowledge I acquired by necessity at Red Hat and
> figured out how to apply it to hg. All the same features are there in
> hg, they're just switched off by default (mainly because the core
> Mercurial devs are adamant that any potentially history destroying
> operation in a version control system must be opt-in). In particular,
> the evolve extension is an impressive tool that allows history to be
> edited in such a way that the edits can be safely shared amongst
> repos.

Often times it’s there multiple times in different incompatible ways so
figuring out which extension to use can be hard. They also have varying
levels of compatibility with other tools. Setuptools uses “bookmarks”
instead of branches sometimes and that confuses bitbucket in some way
that makes bitbucket throw errors at me when I attempt to use it.

I’ve not had much luck personally with the extensions to Hg, they seem
to be second class citizens in terms of workflow and I do think that
them being off by default makes them worse too.

> 
>> Too bad for BitBucket, but most people who started contributing to open
>> source in the past 5 years already have a GitHub account.
> 
> You can log into BitBucket with a GitHub account.
> 
> More generally, I'm very, very disappointed to see folks so willing to
> abandon fellow community members for the sake of following the crowd.
> Perhaps we should all just abandon Python and learn Ruby or JavaScript
> because they're better at getting press in Silicon Valley?

I don’t think this is really fair. It’s not about press, it’s about the
best tool for the job and being pragmatic.

> 
>>> Note that if folks prefer Git, BitBucket supports both. I would object
>>> strongly to unilaterally forcing existing contributors to switch from
>>> Mercurial to git.
>> 
>> What about potential new contributors? And the hg-git bridges that git fans
>> are always referred to work in the opposite direction too... :-)
> 
> We already have lots of potential contributors (if we didn't, review
> bandwidth wouldn't be the bottleneck the way it is today), and the
> functional differences between GitHub and BitBucket from a barrier to
> entry perspective are so low as to be trivial.

That’s not really true. It’s more than just “can I log in”, potential
contributors are more likely to already know how to use Github too and
are more likely to not want to deal with another site. I know personally
if I see a project is on bitbucket my chances of contributing to that
project drop drastically, even if they are using git on bitbucket,
just because I know that I’m going to get frustrated to some degree.

> 
> For organisations with no vested interest in BitBucket or Mercurial,
> sure, they may as well just go with the popular choice.
> 
> Unlike most organisations, we have a vested interest in encouraging
> the growth of the Python ecosystem and community, and the developers
> of both Mercurial and BitBucket are members of that community.
> 
> While we have historically done very little to date in reaching out to
> the Mercurial developers and seek their assistance in improving the
> developer guide, remedying that and providing better Mercurial usage
> guidelines is one of my hoped for outcomes in making it easier for
> others to contribute to the developer guide.
> 
> By contrast, GitHub is a Ruby application, and git is a collection of
> C and shell scripts - they may be tools used *by* the Python
> community, but they are decidedly not products *of* the Python
> community.

Well CPython is a C application so perhaps we should switch to an
interpreter written in Python if the goal is to always pick the
thing that’s written in Python?

> 
> Given the choice between two functionally equivalent solutions, one of
> which lets us continue using the tools we already use (including all
> the associated automation), and is created by members of the same
> development community, I think the burden of proof falls on the folks
> that want to make the backwards incompatible change that the
> additional cost will be worth it.
> 
> Moving from self-hosted Mercurial repos to externally hosted Mercurial
> repos is a low risk change. It reduces maintenance overhead and lowers
> barriers to external contribution, both without alienating existing
> contributors by forcing them to change their workflows.
> 
> Proposing to *also* switch from Mercurial to git significantly
> increases the cost of the change, while providing minimal incremental
> benefit.
> 
> Regards,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA