Release blocker for Go 1.17 via #11811, mostly just as a matter of builder hygiene. (If the builders are so consistently flaky that we don't act on failures, then we shouldn't be wasting builder resources running this repo on them.)

Just out of curiousity, I ran go test -short ./go/packages and go test ./go/packages on my Xeon workstation. The non-short version actually ran one second faster, so I suspect that this package is not currently making use of testing.Short().

These builders do appear to be running go test -short, so adding some short-mode skips for the longer / more esoteric tests should help them avoid timing out.

I agree that builder hygiene is essential, but I am not sure this is a release blocker for Go 1.17 per our Porting Policy.

What do you think?

#11811 is admittedly quite vague on what it means for the builders to be “green”.

My interpretation (in the context of the porting policy) is that for first-class ports we should always fix failing tests prior to release by addressing the root cause (a bug in either the test or the behavior it verifies), but for non-first-class ports we can instead decide to just skip the failing test, stop testing the repo against that builder, or even drop support for the port entirely.

Either way, we should aim to be in a state in which all of the builders that are running are passing reliably. Otherwise we end up with a lot of noise on the dashboards, which leads to failure-blindness and may cause us to miss significant regressions that do affect first-class ports.

I just looked at this briefly. Most of the slow tests are related to overlays or cgo. Skipping 6/74 tests reduced my run time from ~60s down to ~15s on my computer.

@matloob how do you feel about skipping overlay / cgo tests for -short test runs?

Change https://golang.org/cl/331052 mentions this issue: go/packages: skip slow and GOPATH tests in short mode

Change https://golang.org/cl/332351 mentions this issue: go/packages: skip tests that link binaries in short mode

Change https://golang.org/cl/332350 mentions this issue: go/packages: parallelize most tests

The tests for this package have been passing consistently on illumos-amd64, dragonfly-amd64, and netbsd-arm64-bsiegert since CL 331052.