Hi all, I'm Gleb Khmyznikov, a software engineer at Microsoft working on Python ecosystem enablement for Windows on Arm. In an off-list conversation, one of the Arrow maintainers suggested I bring this here as a community discussion.
PR #48539 <https://github.com/apache/arrow/pull/48539> adds win_arm64 build support. From the review discussion, my understanding is that the workflow changes are not the blocker. The real questions are wheel count, having a single Windows build path, and who supports the platform afterwards. What I understand the preconditions to be: 1. Reduce the number of wheels shipped (abi3), so win_arm64 doesn't make the PyPI project size problem worse (see #49822<https://github.com/apache/arrow/issues/49822>). 2. A single, unified build path for Windows rather than a second parallel one. 3. A written support plan for win_arm64: is a win_arm64 wheel failure a release blocker, and who is on the hook when it breaks? What we can commit: * A dedicated engineer for Windows on Arm from Linaro (working through the CoreCollective <https://github.com/CoreCollective-dev/windows-on-arm-wg> Windows on Arm working group) can be assigned to Arrow for triage, testing, and fixes on win_arm64. This is funded work, not best-effort volunteering. * Hardware for maintainers who want to commit into platform support. We can ship Snapdragon X-class device to maintainers on the project who needs to reproduce or debug win_arm64 issues locally. * Engineering time on the abi3 and build-consolidation work itself. Our engineers can do this work as contributors, under the PMC's direction and review, rather than leaving it as a prerequisite that falls to existing maintainers. This benefits Windows amd64 too, not just arm64. We would need guidance on the design you want before we start writing patches. * A named escalation contact and a monitored channel for win_arm64 CI failures, so a release manager never has to debug an Arm-only failure alone. Proposed support policy (starting point, not a demand): * win_arm64 wheels are explicitly NOT a release blocker initially. If they fail, the release proceeds without them. * Nightly / non-release builds first, so the community can see the failure rate before it touches the release matrix. * Promotion into the release matrix only after a defined period of stable CI and only if the PMC is comfortable at that point. Two things worth noting on CI: GitHub-hosted Windows Arm64 runners are now maintained by GitHub directly, and the images have improved substantially over the past year. Questions for the list: * Is the sequencing above right, i.e. abi3 and unified Windows build first, win_arm64 after? * If our engineers take on the abi3 and build-consolidation work, who would be the right person to align with on the intended design, so the patches arrive in a shape the PMC actually wants? * Does the non-blocking, nightly-first support policy address the maintenance concern, or is there something else you'd want to see? I'm not asking anyone to take on unpaid work, and I'd rather get this right than push it through. Happy to adjust any part of this based on what the community thinks would actually make it a net positive for Arrow. Thanks, Gleb Khmyznikov Microsoft
