[Python-Dev] Helping contributors with chores (do we have to?)

Paul Moore p.f.moore at gmail.com
Sun Jun 25 17:39:36 EDT 2017

On 25 June 2017 at 18:31, Donald Stufft <donald at stufft.io> wrote:
> I have used it. I don’t use it every day but I’ve never had it fail on me
> unless the contributor has unchecked the flag. I just ``git remote add
> <github username> <github url>`` then checkout their branch, add more
> commits, and push to their branch.

That's relatively simple, but not immediately obvious (at least to me).

There's a lot of concepts in here that are not exactly basic:

1. Being allowed to have multiple remotes in one repository
2. Naming of branches in non-default remotes, and how to translate the
name in the remote to the local name you need to use
3. Pushing to non-default remotes

There's also the point noted that by default, github doesn't permit
this usage, and the contributor has to explicitly allow it - which
probably means the core dev need to know how to do it, and how to
explain that process to the contributor.

And probably others. I'm not interested in debating what constitutes
stuff that "everyone should know", or how "easy" or not git is. But
for someone coming from a familiarity with Mercurial (which means many
core devs) the learning curve is pretty steep (I'd consider that
self-evident, because of the differences between the 2 systems).

The decision to move to git/github has been made. It's not up for
debate whether core devs need to learn to deal with it. But we do need
to acknowledge that there's a significant learning curve, and while
core devs are contributing from their free time, learning the new
tooling is a major distraction from what they actually want to do,
which is work on Python code.

I don't have a good solution, but I do think we need to acknowledge
the issue and address it without making judgements on what other
people are familiar with or not.


PS There's a *lot* of stuff going by in the core-workflow list - the
new blurb and cherry-picker tools, lots of workflow recommendations,
etc. I haven't even looked at most of them yet, which means I'm
accumulating an increasing load of work I can do before I get back to
the point where I can contribute (and I'm familiar with git). Finding
the time to pay off that debt is getting harder and harder...

More information about the Python-Dev mailing list