For reference, the open issues for windows/arm64:
https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3AOS-Windows+label%3Aarch-arm64

• cmd/go,os: build cache checksum errors in x/tools/cmd/callgraph.TestCallgraph on windows/arm64 #50706 in particular is one I recall having discussed as a potential blocker for promoting the port to first-class.

This one seems like a similar kind of weird flakiness, given @qmuntal's comment about 274GB:

• x/build: "fatal error: out of memory" on windows-arm64-11 #51019 (comment)

CC @golang/windows

CC @golang/release

It would be good to have some eyes on the issues that @bcmills pointed out above.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

What benefits of being first class are you trying to achieve? Note that we ship binaries for all ports now.

I'm still curious what benefits of being first class you are trying to achieve.

The main thing that would give us pause about declaring it first class is that we don't have the builder bandwidth to really hammer on tests the way we do for the other first class ports, including for presubmits. Our new build infrastructure LUCI can treat Azure as a reverse builder but does not know how to autoscale. The same scaling issues affect the macOS port, but we do have more builders there. I am not sure about their relative speeds.

@dagood, @qmuntal, and @gdams, any thoughts on the questions above?

The main thing that would give us pause about declaring it first class is that we don't have the builder bandwidth to really hammer on tests the way we do for the other first class ports, including for presubmits.

Agree, windows/arm64 builders are not scalable right now and they tend to hang every now and then (see #58604). I would like to fix that regardless of the outcome of this proposal. @gdams can help getting some more Azure resources and provide guidance to implement whatever autoscale pieces missing.

What benefits of being first class are you trying to achieve? Note that we ship binaries for all ports now.

Broken first-class port builds block releases. This is an important benefit for obvious reasons. On the other hand, the @golang/windows team currently has a skeleton crew now that @bcmills left Google, and I'm taking a 4-months paternity-leave soon. Given this situation, I would rather put this proposal on hold until we have more bandwidth to properly support windowd/arm64 as a first class port.

Placed on hold.
— rsc for the proposal review group