[core-workflow] What would it take to split the stdlib out into its own git repo?

[Brett Cannon]

What would be involved in making the stdlib its own repo, separate from
CPython itself? Now I'm not suggesting making sure it fully functions on
its own, but more of what would need to happen if we decided that the
stdlib should be  its own git repo so that any Python implementation --
including CPython -- would include the stdlib as e.g. a git submodule? For
instance, would we be able to split the history, or would the original
history stay in the CPython repo and we would start from scratch in the
stdlib repo and `git log` would hopefully be smart enough to merge the two
histories? How bad is it to work in a repo with a submodule where you will
be making changes to submodules regularly?

And are there benefits? My hope/hunch is that if we make the stdlib its own
repo then other implementations could include the stdlib as a submodule or
something, making it easier for them to not only keep up-to-date with fixes
to the stdlib, but also make it easier for them to push changes upstream
that everyone would benefit from instead of having any changes silo-ed off
in their own repo.

Am I nuts, or is this something reasonable to consider doing as part of the
GitHub migration?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160717/523480f7/attachment.html>