[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

[Donald Stufft]

> On Nov 30, 2014, at 2:08 AM, Larry Hastings <larry at hastings.org> wrote:
> 
> 
> On 11/29/2014 04:37 PM, Donald Stufft wrote:
>> On Nov 29, 2014, at 7:15 PM, Alex Gaynor <alex.gaynor at gmail.com> <mailto:alex.gaynor at gmail.com> wrote:
>>> Despite being a regular hg
>>> user for years, I have no idea how to create a local-only branch, or a branch
>>> which is pushed to a remote (to use the git term).
>> I also don’t know how to do this.
> 
> Instead of collectively scratching your heads, could one of you guys do the research and figure out whether or not hg supports this workflow?  One of the following two things must be true:
> hg supports this workflow (or a reasonable fascimile), which may lessen the need for this PEP.
> hg doesn't support this workflow, which may strengthen the need for this PEP.
> Saying "I've been using hg for years and I don't know whether it supports this IMPORTANT THING" is not a particularly compelling argument.
> 

Comments like this make me feel like I didn’t explain myself very well in the
PEP.

While I do think that supporting this workflow via an extension is worse than
supporting it in core, this isn’t why this PEP exists. The current workflow for
contributing is painful, for the repositories this is talking about if I’m a
non-comitter I have to email patches to a particular closed mailing list and
then sit around and wait.

The Pull Request based workflow is *massively* better than uploading/emailing
patches around. So the question then becomes, if we're going to move to a PR
based workflow how do we do it? PEP 474 says that we should install some
software that works with Mercurial and supports Pull Requests. Another thread
suggested that we should just use to bitbucket whicih also supports Mercurial
and use that.

This PEP says that git and Github have the popular vote, which is extremely
compelling as a feature because:

* Popularity is the one thing you can't replicate featurewise. This feature or
  that you can find a way to work something like it out.
* With popularity comes the fact that people will already know the tooling
  involved and how to use it. This means that a new contributor whom already
  knows git will spend less time learning our specific toolset and more time
  being able to meaningfully contribute.
* With popularity also comes transferability, If I don't currently know a VCS
  tool and I learn git (and github) for the sake of these repositories then
  that knowledge will directly transfer to greater than 60% of the top 100
  projects on PyPI.
* With popularity also comes an increased amount of people writing about it,
  asking questions, etc. This means that if I have a problem while using this
  tool I am more likely to find someone who already had this problem and they
  are more likely to have found someone to help them solve it than I am with
  a less popular tool.

I'm not sure why people seem to try and focus on the fact that with this
extension or that you can make Mercurial replicate git better when that isn't
really the major point of the PEP at all. If Mercurial and git were neck in
neck in terms of mindshare and bitbucket and Github were as well then this
PEP probably wouldn't exist because on a techincal level I think the two tools
are probably close enough. However when most of the world is using one tool
and you're using another, that does represent a barrier to entry.

---
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/20141130/9716f904/attachment.html>