I would like to propose officially defining a development upstream, and enforcing it.

The solution that I think would more cleanly handle fragmentation, history, authorship, and CLA issues, is to select CPython as the upstream. An approach to implement this could be to track the backport version here, and when updated, have CI automation to update the backport repos, just like we do to backport to older Python versions.

While I think that's cleaner, it is a major change to how these modules are currently developed, and the implementation might be too complex, so I think it's more likely for us to go with the backports as the upstream. If so, there are a couple things I think we should do:

• Add issue tags for each backport, which, once assigned, would cause the issue to be moved to the correct repo
• Prevent PRs from changing the code (with a manual override)
• Implement some level of automation for the synchronization operation, preserving commit authorship (perhaps even history)
• Document the synchronization process
• Have the backports maintain a copy of the correspondent CPython documentation, instead of having its own
• Add the CLA bot to the backports

select CPython as the upstream

I think that this makes sense, especially as both of the importlib modules are no longer "provisional". Useful parallels can be drawn with PEP 360, which used to record "externally maintained" packages, and was updated in 2006 to say:

It has been deemed dangerous to codify external maintenance of any code checked into Python’s code repository. Code contributors should expect Python’s development methodology to be used for any and all code checked into Python’s code repository.

Another parallel is the changes to Pathlib that Barney has recently been making. He published the pathlib-abc package as a backport/preview, rather than primary development being in that package.

Whilst having a brief look at the history, I found that Jason noted in a comment from a few years ago that:

The advantage of having the module in the standard library is that at some point, the pace of change should slow and the stdlib can become the primary/only use.

The other two recently externally-developed modules seem to be tomli and zoneinfo (please let me know if I'm missing any).

Three of the four PRs to tomllib since it was added as a package were to synchronise with tomli as an upstream (#128907, #126428, and #124587). These have each been quite minor, and each has been opened as an individual PR, rather than an omnibus "sync with version X" update.

zoneinfo used to have some sync PRs, but the last one seems to be four years ago (#20499), and the backport package has not been updated for two years (last release 2020-06).

There have also been some problems with synchronising the documentation, as the d.p.o documentation used to point to the backport (python/importlib_metadata#485), with one user going so far as to manipulate Sphinx internals (stefan6419846/license_tools#63) to solve this problem. Ultimately, documentation was removed from the backport package (python/importlib_metadata#466).

To Jason's quoted comment above about pace of development eventually slowing, I wonder if at some point we should seek to update the backport packages less frequently, and to mirror Python releases. There is prior art for this with zipfile3{x} packages on PyPI. This would ease the burden of the actual backporting, as it would be done less often. The backport package could also use a rebase or fast-forward merge, which would preserve authorship details.

As such, I would be in favour of this python/cpython repo being the one where new features are developed, discussed, and merged for importlib.resources and importlib.metadata (and also tomllib).

A