[core-workflow] My initial thoughts on the steps/blockers of the transition

[Barry Warsaw]

On Jan 05, 2016, at 12:42 AM, Brett Cannon wrote:

>The way I see it, we have 4 repos to move: devinabox, benchmarks, peps,
>devguide, and cpython.

Arthur: Each core dev converts four repos...
Knight: Five repos
Arthur: He who converts the repos four...
Knight: Five repos
Arthur: Five repos may hack in safety

>There are six things to work out before we move over cpython. First, do we
>want to split out Python 2 branches into their own repo? There might be a
>clone size benefit which obviously is nice for people on slow Internet
>connections. It also clearly separates out Python 2 from 3 and lets those
>who prefer to focus on one compared to the other do that more easily. It
>does potentially make any single fix that spans 2 and 3 require a bit more
>work since it won't be an intra-clone change. We could also contemplate
>sub-repos for things like the Doc/ or Tools/ directories (although I doubt
>it's worth it).

I suspect cherry-picking between Python 2 and 3 branches won't be very smooth
no matter what approach is chosen.  Still, it's probably just as easy to keep
everything in one repo.

>Second, do we want all fixes to go into master and then cherry-pick into
>other branches

IME, yes, that usually works the best for the person doing the cherry picking.
It also seems that all contributed PRs are always just made against master
anyway.

>We should build a bot. It must use a Monty Python reference to trigger
>(black-knight, none-shall-pass, man-from-scene-24, five-questions,
>what-is-your-quest, what-is-your-favourite-colour, etc.; obviously I'm
>leaning towards the Black Knight or Bridge of Death

You've clearly done your homework!  Which probably involved watching MPatHG at
least 10 times. :)

Something else to consider.  We've long talked about splitting out the stdlib
to make it easier for the alternative implementations to import.  If some or
all of them also switch to git, we could do that pretty easily with git
submodules.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160104/8cbb158d/attachment.sig>