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.

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.

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?

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.

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://golang.org/wiki/PortingPolicy#requirements-for-a-new-port for future ports, although it is also possible to do this retroactively as long as we always have someone who agreed to maintain the port.

@aclements suggested that we could pretty easily create GitHub teams for port owners. I really like that idea: it would be immediately useful in issue triage (because it would enable GitHub autocompletions), and wouldn't require any code whatsoever in the devapp server.

I'm not 100% certain who the correct owners are today; I've more or less cobbled together information from the current builder owners and recent issue activity.

Folks mentioned below: please respond with 👍 if you want to be added to all of the teams I've suggested for you, or 👎 if you're not an active Go port owner (and shouldn't be added to any of the GitHub teams), or add a comment for other corrections.

Please also add a comment if you are (or know of) a Go port maintainer that I have missed here!

For GOOS (darwin, linux, and windows have first-class ports):

• @golang/aix: @ayappanec (builder owner)
  • @laboger, @pmur, @archanaravindar
• @golang/android: @steeve, @changkun (builder owners)
• @golang/dragonfly: @tuxillo (builder owner)
• @golang/freebsd: @paulzhol, @dmgk (builder owners)
  • @ayang64, are you also an active maintainer for this Go port?
• @golang/illumos: @jclulow (builder owner)
• @golang/ios: @steeve, @changkun (builder owners)
• @golang/js: @neelance (but maybe this is redundant with @golang/wasm?)
• @golang/netbsd: @bsiegert (builder owner)
  • @coypoop may also be a Go port maintainer?
  • @4a6f656c, are you also an active maintainer for the NetBSD port?
• @golang/openbsd: @4a6f656c (builder owner)
  • @beoran?
• @golang/plan9: @0intro (builder owner), @millerresearch (plan9-arm builder maintainer)
  • @fhs?
• @golang/solaris: @rorth (builder owner)
• @golang/windows
  • windows/amd64 and windows/386 are first-class ports, but it may be useful to add a GitHub team for expertise anyway..?
  • Probably @alexbrainman; perhaps @zx2c4 and/or @mattn too?

For GOARCH (386, amd64, arm, and arm64 have first-class ports):

• @golang/arm:
  • linux/arm and linux/arm64 are first-class ports, but we may want a group for contributors with particular expertise.
  • Maybe @zhangfannie?
• @golang/mips: @mengzhuo, @bogojevic, @milanknezevic, @4a6f656c (builder owners)
  • Note that I've lumped together all of the 64/32 and BE/LE variants into one group. 😅
• @golang/ppc64: @laboger, @pmur, @archanaravindar, @ceseo
  • This would cover both ppc64 and ppc64le.
• @golang/riscv64: @4a6f656c, @mengzhuo (builder owners)
• @golang/s390x: @jonathan-albrecht-ibm, @cwsolee, @sangitanalkar (builder owners)
• @golang/wasm: @neelance

There are also a couple of special ports and builders that I want to explicitly call attention to, although I'm not sure whether or how to surface that information in GitHub.

• The windows-amd64-wsl builder is not itself a first-class platform, but straddles a line between two first class ports (windows/amd64 and linux/amd64). It builds from linux/amd64 source and doesn't normally require specialized code, but does sometimes need test-skips or diagnostics for platform-specific bugs or test failures.
  • The builder is operated by @mengzhuo.
• windows/arm64 has a builder operated by the Go team, but is not yet a first-class port. (It's in a bit of an awkward state where the Go team isn't formally responsible for it but operates it anyway.)
  • @rsc generally looks into problems on this platform if they are pressing.
• windows/arm and linux/loong64 are to my knowledge incomplete ports.

Is it possible for me to add other illumos community members to the team myself later, or is that something I should open a ticket for?

@bcmills I could help with arm64 as well, if you need more people.

@bcmills -- no, i'm not an active maintainer of golang/freebsd. i'd like to be though.

@jclulow, you could add other folks by filing an issue in this repo (just like we do for other kinds of GitHub access).

@ayang64, since this is mostly for routing issues during triage, I'd be happy to include you in the list — all it takes to be an active maintainer is to actively help fix things that break. 😃

@pmur, @archanaravindar and I work on ppc64le/ppc64 on Linux and since the assembler and compiler for AIX is the same we could handle codegen specific issues for AIX as well. @Helflym is no longer on AIX, I'm trying to get the names of those who are taking over for him to handle runtime and linker issues for AIX. I don't think @ceseo would work on triage/support anymore.

@laboger I could. I still review your patches anyway.

SGTM
linux-amd64-wsl also operated by @oiooj

@bcmills I would like to join. And @erifan also works on linux/arm64, he is also willing to help. Thank you.

@laboger I could. I still review your patches anyway.

@ceseo I don't think you should be listed as the primary owner for debugging and fixing problems, as shown in the table above. Reviews are fine.

@bcmills, @ruixin-bao is no longer an s390x builder owner. I opened an CL a while back to remove him from the list: https://go-review.googlesource.com/c/build/+/370879

@bcmills, please add Cindy Lee (@cwsolee) and Sangita Nalkar (@sangitanalkar) to the s390x list

I'm happy to take a look at arm/arm64 issues. Thanks.

Apologies to those who have already responded, but apparently GitHub caps my ability to see who has thumbs-up'd a post at 10. Since there are not currently any thumbs-downs, I'm going to proceed with adding everyone who doesn't comment otherwise to the respective groups. 😅

Count me in for Windows. 👍

Yes, please (for Windows)

I've created the GitHub teams above, as subteams of @golang/port-maintainers. Please let me know if there are any problems or revisions.

Given the GitHub teams, I'm going to close this issue — let's see how far we get with just that, and if we decide that it would still be useful to make changes to devapp too we can open a new issue to discuss the tradeoffs.

Apologies to those who have already responded, but apparently GitHub caps my ability to see who has thumbs-up'd a post at 10

Just a trick: If you open this thread on GitHub mobile client (iOS, not sure about Android), hold the thumbs up emoji, then the interface will show a list of users who clicked thumbs up :)

Yes, please, for Windows.

@bcmills I do not use openbsd myself, i just complained once when they started to insist that we call the kernel through the C library. I am much more familiar with the low level Linux kernel, so I could answer questions for that. But I cannot contribute code because i am opposed to CLAs.

Yes, I am in. linux/loong64 👍
Please also add @chenguoqi-cc @limeidan

Thanks!

Yes, I am in. linux/loong64.

@tklauser Would you be okay with being added to @golang/netbsd?

Sure, happy to be added to @golang/netbsd

Hi @bcmills , seems @zhangfannie is not in @golang/arm , could you please add her to this team, thanks.

@erifan There's a pending invitation that @zhangfannie needs to accept. Maybe check if it went to spam by mistake? We can resend the invitation if it's lost. Thanks.

When I received the email, I just clicked accept in the invitation email and forgot to continue the enable operation. I just finished it. 😊
Thanks @dmitshur and thanks for @erifan's reminder.