Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bcmills opened this issue Nov 5, 2018 · 5 comments

Comments

@bcmills
Copy link
Member

commented Nov 5, 2018

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)

@bcmills bcmills added this to the Unreleased milestone Nov 5, 2018

@bradfitz

This comment has been minimized.

Copy link
Member

commented Nov 5, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 5, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 5, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 5, 2018

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

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

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

image

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.