proposal: build: promote windows/arm64 to first class port

[dagood]

Proposal Details

We (@qmuntal, @gdams, and I--Microsoft folks) think the windows/arm64 port is at a point where it fits https://go.dev/wiki/PortingPolicy#first-class-ports and can be promoted.

Specifically: the windows/arm64 builders have been running for a while and don't seem to have unreasonable maintenance problems, and the builders are operated by the Go team.

I'm raising this proposal to see if it's time, or to find out if there's anything we can help with to get it there.

Follows up on this comment and issue:

• clarify Go support policy for secondary ports #53383 (comment)
• x/build/env/windows/arm64: add Windows arm64 builders provided by Microsoft #53541

[bcmills]

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

[bcmills]

• 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.

[dagood]

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)

[ianlancetaylor]

CC @golang/windows

[ianlancetaylor]

CC @golang/release

[rsc]

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

[rsc]

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

[rsc]

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

[rsc]

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.

[rsc]

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

[qmuntal]

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.

[rsc]

Placed on hold.
— rsc for the proposal review group

[thanm]

See also #66962 (comment).

At the moment due to the instabilities described there the LUCI windows-arm64 builders seem to only stay usable for 4-7 days before they have to be rebooted.