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

[Nicholas Chammas]

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.

Not to derail here, but wasn’t there a discussion (perhaps on python-ideas)
about slowly moving to a model where we distribute a barebones Python
“core”, allowing the standard modules to be updated and released on a more
frequent cycle? Would this be one small step towards such a model?

Nick
​

On Mon, Jan 4, 2016 at 9:43 PM Barry Warsaw <barry at python.org> wrote:

> 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
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160105/0f9eec56/attachment.html>