Go: x/build/devapp/owners: add owners for less-common GOOS and GOARCHes

[bcmills]

https://dev.golang.org/owners/ currently lists owners for code components.

However, some issues seem to be specific to a particular GOOS or GOARCH, and in order to diagnose those issues it's helpful to get input from someone with platform-specific expertise (@alexbrainman, @mundaym, @ceseo, @0intro, @neelance, and surely others I'm forgetting).

I've learned a few of those platform-to-expert mappings, but it would be helpful to codify them more explicitly. Can we put them in devapp/owners somewhere, perhaps in a parallel table?

(CC @bradfitz @dmitshur)

[bradfitz]

SGTM.

Or we could just add owners for the GOARCH directories:

bradfitz@gdev:~/go/src$ ls cmd/compile/internal/
amd64  arm  arm64  gc  mips  mips64  ppc64  s390x  ssa  syntax  test  types  wasm  x86

But for GOOS, we don't really have directories in general. We just have lots of +build files for runtime & syscall, etc. So maybe we do need an explicit mechanism to record these.

In the meantime I can often find owners by looking at https://farmer.golang.org/builders but that's not quite sufficient.

[bcmills]

GOARCH directories seem like the logical place for that.

Perhaps we could list GOOS owners as owners under build/env? But then we would need some way to identify owners for GOOS values that don't have a corresponding build/env directory: aix, android, dragonfly, hurd, and zos IIUC.

[bcmills]

Hmm, all of those except for hurd and zos have Owner entries in the Hosts and Builders tables in x/build/dashboard/builders.go. So perhaps we could surface those as owners of paths like build/dashboard.Builders/aix-ppc64?

[bradfitz]

Yeah, good idea, we could make the devapp dashboard use the data from the x/build/dashboard.{Config,HostConfig} data structure directly. Then they don't get out of sync.

[dmitshur]

I prototyped the idea of using the owner data from x/build/dashboard described above. /cc @jayconrod

It was informative to try it, but I don't think we can proceed with that approach. According to golang.org/wiki/PortingPolicy:

• At least one developer must be named (and agree) to maintain the port, by making required updates in a timely manner as architecture or operating system requirements change.

• A developer must be named (and agree) to maintain the builder, the machine trying each git revision and providing data for http://build.golang.org.

The data in x/build/dashboard corresponds to builder owners, not necessarily the port owners.

I think we need to make a new manually-curated table in owners and start adding people to it, getting their consent in the process. We should make adding a port owner to the table a part of https://github.com/golang/go/wiki/PortingPolicy#requirements-for-a-new-port for future ports.