Page MenuHomeFreeBSD

misc: Add a map of FreeBSD IDs to GitHub IDs
Needs ReviewPublic

Authored by markj on Apr 17 2024, 8:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Jun 5, 5:20 PM
Unknown Object (File)
Thu, May 23, 8:48 PM
Unknown Object (File)
May 10 2024, 4:25 AM
Unknown Object (File)
May 3 2024, 11:33 AM
Unknown Object (File)
Apr 26 2024, 9:02 PM
Unknown Object (File)
Apr 19 2024, 5:32 PM
Subscribers

Details

Reviewers
andrew
emaste
imp
Summary

This is just for discussion.

Also add an awk script which can look up GitHub IDs given a FreeBSD
username. Provide a partially populated map file.

Questions:

  • Should this live in the src repo? Does it make sense to have it somewhere else?
  • Can we use this to auto assign reviewers to github PRs? The idea would be that we have a separate set of rules which map source paths to maintainers or groups of maintainers, e.g., sys/arm64/arm64/* -> andrew@. Then, a github action can parse these rules, lookup andrew@'s github ID, and run gh pr edit --add-reviewer to modify the PR.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 57148
Build 54036: arc lint + arc unit

Event Timeline

markj requested review of this revision.Apr 17 2024, 8:39 PM
markj created this revision.

IMO this is sensible to be in the repo, but in share/ doesn't feel right

share/misc/github_ids
9

Some of this can be found with
curl -i -s 'https://api.github.com/search/users?q=$USER@freebsd.org'
but only if the FreeBSD address is the primary email.
I've not found how to lookup by secondary email.

<grumpy>I am personnally not sure of the usefulness of this file (why not the same for ht.st, codeberg, gitlab etc?</grumpy>
<contructive>the github organization for the project is maintained (partially) as code so the who ask themselves to join the freebsd organization who are committers are in a terraform file on the clusteradm repo with both their github id and their freebsd id if this can help</constructive>

<grumpy>I am personnally not sure of the usefulness of this file (why not the same for ht.st, codeberg, gitlab etc?</grumpy>

No reason except that we use github and not so much the others. If that changes, we should add similar maps for them if needed.

More broadly, my goal is to revive the use of MAINTAINERS. In particular I would like to be able to map a set of src paths to one or more committers who volunteer to review and commit patches from contributors. So, one can ask the question, "which developer(s) should be the first to look at patches for sys/amd64/amd64/machdep.c?" and automatically get an answer. Then, in order to automatically add reviewers to a github PR, we need to be able to map the answer to a set of github IDs.

This same mechanism (MAINTAINERS) should be used to generate herald rules in phabricator, and whatever other review system we might use in the future. Right now, we use herald rules to auto-add reviewers in some cases, but that's only useful for phabricator. The source of truth for maintainership information should live in the src repo, not in phabricator as a set of herald rules. (And not in .github/CODEOWNERS or any other platform-specific encoding.)

<contructive>the github organization for the project is maintained (partially) as code so the who ask themselves to join the freebsd organization who are committers are in a terraform file on the clusteradm repo with both their github id and their freebsd id if this can help</constructive>

This might be useful - I guess the first question which needs to be answered is whether this mapping should live in the src repo. If this terraform file could be queried remotely somehow, then we probably don't need my patch here.