Suggest maintainers
adamjstewart opened this issue · comments
When a package does not yet have any maintainers listed, we suggest that the PR author be a maintainer. However, we could also suggest contributors who have modified this package in the past (via spack blame), or GitHub contributors to the actual software if it's hosted on GitHub.
It's too bad that we can't get at GitHub's suggested reviewers via the API -- looks like there is no endpoint for it.
Spack blame doesn't actually include any GitHub alias, so we'd need to add that.
Looks like we need a link between GitHub alias and email - this might be too much for just this command (and trying to keep an updated records that match emails to GitHub alias)
author Todd Gamblin
author-mail <tgamblin@llnl.gov>
author-time 1538945543
author-tz -0700
committer Todd Gamblin
committer-mail <tgamblin@llnl.gov>
committer-time 1539812526
committer-tz -0700
summary relicense: replace LGPL headers with Apache-2.0/MIT SPDX headers
previous 3501bc91247042dd78813094e1218ff1ac2e7d13 lib/spack/spack/fetch_strategy.py
filename lib/spack/spack/fetch_strategy.py
# Spack Project Developers. See the top-level COPYRIGHT file for details.
9bd4bc02d6dfa60485e193d994a504c01e4d51e1 1 3 1Blame is only in GraphQL unfortunately https://docs.github.com/en/graphql/reference/objects#blame
@adamjstewart how about we suggest to the person that they run spack blame to look up people that have worked on the package? The issue is that a person that has worked on a package hasn't really signed up to get these notifications (whereas a maintainer has) so they could get annoying. The second issue is that we would need to allow a person to opt out of being notified the first time if they aren't interested so it doesn't happen again, and that would require spackbot storing some kind of state (which is also hard to do). So - I'll do a quick PR that adds the suggestion for spack blame for now.