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

[Terry Reedy]

On 11/30/2014 2:33 PM, Donald Stufft wrote:

> So a goal of mine here is to sort of use these as a bit of a test bed.
> Moving CPython itself is a big and drastic change with a lot of
> implications, but moving the “support” repositories is not nearly as
> much, especially with a read only mirror on hg.python.org
> <http://hg.python.org> which would allow things like the PEP rendering
> on www.python.org <http://www.python.org> to stay the same if we wanted
> to. My hope was that we’d try this out, see how it works out, and if it
> seems to be a good thing, then at a later time we can either look at
> moving CPython itself or decide if it makes sense to do something
> different. Maybe this should be spelled out in the PEP?
>
> I’ve seen a few people say they were -1 because they didn’t want to
> split between hg on the CPython side and git on the supporting repos
> side.

Being only recently somewhat comfortable with hg, I do not really want 
to have to learn git at this time.

> I’m not sure you can really get away from that because we’re
> *already* in that situation, things like the docs building script is a
> Git repo on Github,

As long as I can do test doc builds with the scripts in /Docs, this does 
not matter to me.  If the people who work with the site doc build script 
want it in git on Github, fine.

> the python infrastructure itself is a git repo on Github,

Since I am not sure what you mean, its location does not matter to me.

 > the new python.org <http://python.org> website is a git repo on
> Github, the future PyPI is a git repo on GitHub.

Since I do not commit to either, ditto.  As far as I am concerned, the 
people involved with specialized repositories may as well have their 
preference.  This includes devinabox.

I have made a few commits to the PEP repository, but only to the one I 
co-authored, 434. Using the web form might make it easier to suggest 
changes to other peoples' PEPs.

> IOW I’m not sure what the best way forward is. I think moving to these
> tools for *all* repos is likely to be in the best interests of making
> things better for both sides of that coin however I didn’t want to go
> wholesale and try and make everything switch at all at once.

I agree with others that the current bottleneck is disposing of patches, 
especially those from non-core developers, not getting more patches to 
considier.  I am quite sure that if we significantly reduce the current 
backlog of 4600 issues and more expeditiously handles the contributions 
we do get, will will get more.  More than one person has said that they 
are disinclined to submit patches when they have multiple patches on the 
tracker already.

So I think the focus should be on making better use of developer time 
and having more of it.

-- 
Terry Jan Reedy