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

[Terry Reedy]

On 11/30/2014 4:45 PM, Donald Stufft wrote:

I think you are stimulating more heated discussion than is necessary by 
trying to do too much, both in terms of physical changes and in terms of 
opinion persuasion.

I am reminded of the integer division change.  The initial discussion 
was initially over-heated partly because the actual change to Python was 
coupled, quite unnecessarily, with a metaphysical opinion as the the 
ontological status of natural numbers versus integers -- an opinion that 
many, including me, considered to be wrong.  Once the metaphysical 
question was dropped, discussion went more smoothly.

> Here’s another idea for an experiment that might be more generally useful.

I think a true experiment with one repository is easily justified.  The 
PEP repository is an obvious choice because a) the main editor is in 
favor, b) many but not all core committers interact with it, and c) it 
is not tied to the tracker.  The easier and more controversial option 
would be to move it completely to GitHub.  I expect part of the result 
would be pull requests from committers who would otherwise commit 
directly to hg.  The harder and, I think, more useful (generalizable) 
option would be to set up a mirror (or keep the hg version as a mirror 
;-) and experiment with coordinating the two mirrors.

Such an experiment should not preclude other experiments.  If Brett 
wants to similarly experiment with devinabox on another site, let him. 
If the horrible-to-Nick prospect of possibly moving CPython to GitHub, 
if nothing else is done, provokes Nick to improve the workflow 
otherwise, great.

If the mirror experiment is successful, the devguide might be the next 
experiment.  It does not have any one maintainer, and *is* tied to the 
tracker.  But herein lies the problem with the devguide.  There are 22 
issues, down just 1 from about a year ago.  All but 2 are more than a 
year old.  Many (most?) have patches, but enough consensus for anyone to 
push is hard.  As with other doc issues, there is no 'test' for when a 
non-trivial patch is 'good enough' and hence, in my opinion, too much 
bikeshedding and pursuit of the perfect.

> As we've said there are two sides to the coin here, non-comitters and
> comitters, a lot of the benefit of moving to Github is focused at
> non-comitters although there are benefits for comitters themselves.

For maintaining Idle, I do not see the benefit.  Downloading patches 
from the tracker to my dev directory is trivial. I then apply to the 
current 3.x maintenance version, possibly with some hand editing, revise 
(always, that I can remember), and test.  Once satisfied, I backport to 2.7.

> What if we focused an experiment on the benefits to non-comitters?

Users benefit by more patches being applied.  How do non-commiters 
benefit, really, by making it easier for them to submit patches that sit 
for years?  Ignore that.  Guido says that working with PEPs on GitHub 
would benefit him as a committer.

> It's possible to maintain a git mirror of a Mercurial repository, in fact
> we already have that at github.com/python/cpython
> <http://github.com/python/cpython>. What if we permit people
> to make PRs against that repository, and then take those PRs and paste them
> into roundup? Sort of like the "Remote hg repo" field. Then we can
> create some integration that would post a comment to the ticket whenever
 > that PR is updated
> (sort of like the notification that happens when a new patch is uploaded).
> The cannonical repository would still be hg.python.org
> <http://hg.python.org> and in order to actually
> commit the PR commiters would need to turn the PR into a patch
> (trivially easy, just add .diff or .patch to the PR URL).

This would be the focus of an experiment with the devguide, even if we 
have to generate some somewhat artificial pull requests for testing.  I 
really hope you try to make the above work.

The 3rd stage would be to expand on the above for doc patches. This is 
one area where we would get small ready-to-commit patches -- that do not 
need to be reported to the tracker.  Would it be possible to automate 
the following? Turn a doc PR into a patch, apply the patch to all 3 
branches (perhaps guided by the PR message), and generate a report, 
along with, currently, a 2.7 and 3.4 PR.  (I am thinking about how to do 
some of this doc patches with hg on windows.)

[snip premature discussion of moving cpython 'wholehog' to github.]

Summary research plan: 3 experiments, each depending of the preceding.
1. Link 2 repositories, one with pull requests
2. Link the PRs with the tracker
3. Make PRs work better with our multibranch, 2-head monster.
Report after each experiment (ending with 'success' or 'give-up').

-- 
Terry Jan Reedy