@dustin has been ill this week. He, @zwol, and I spoke earlier this week, and based on that I am speaking in his/our stead on this, and have made a draft roadmap for manylinux2014 rollout.
Reasons the manylinux2010 rollout snagged and went too slowly:
- it wasn’t clear who should be doing what (often partly because of scarce maintainer time)
- there were a few competing PRs implementing the build environment and it wasn’t clear who should review things (ditto)
- the order of operations wasn’t clear until Nick wrote up the tracking issue
- we haven’t ensured ALL helper utilities support
manylinux2010, like cibuildwheel, multibuild, and dockcross, and that’s slowed down adoption - we haven’t concisely explained stuff like “now do x, it’s safe and it’s now the recommended approach, this is orthogonal to
distutils/setuptools/flit/poetry/ and similar kinds of packaging tooling choices, here are the consequences of changing your build environment, these are the compiler gotchas, these are the ways we’re deprecating support for things your users may still want” and spread that message in the right places
Thus, in order to make the manylinux2014 rollout go smoother, we will:
- identify interested parties early and get tentative commitments for work (seeking volunteers as well as institutional support for development, technical advisory, code review, test case inventory, testing, infrastructure-building, personnel gathering and management, maintainer outreach, documentation, bug tracker caretaking, and outward-facing online community liaison work)
- have a roadmap upfront
- in that roadmap and in the rollout, ensure that adding documentation to the Python Packaging Guide is a first-class priority
- point people to
manylinux2010issues that will help them buildmanylinux2014equivalents
@pf_moore I hope this begins to address your concerns – thank you for making this request.