Document use of the maintainers field#12270
Conversation
lib/spack/docs/packaging_guide.rst
Outdated
| for their own software, as well as users who rely on a piece of | ||
| software and want to ensure that the package doesn't break. It | ||
| also gives users a list of people to contact for help when someone | ||
| reports a build error with the package. |
becker33
left a comment
There was a problem hiding this comment.
LGTM. Thanks for documenting this!
|
Ping @tgamblin |
|
Ping ping |
|
I kind of want to get the action working before merging this. |
|
@tgamblin I'm going to refactor this PR (now that the docs have been split) and remove the word "automatically" for now. That way people can still know to add maintainers that can be manually notified. |
31222ce to
fe00be7
Compare
| #. Add a comma-separated list of maintainers. | ||
|
|
||
| The ``maintainers`` field is a list of GitHub accounts of people | ||
| who want to be notified any time the package is modified. When a | ||
| pull request is submitted that updates the package, these people | ||
| will be requested to review the PR. This is useful for developers | ||
| who maintain a Spack package for their own software, as well as | ||
| users who rely on a piece of software and want to ensure that the | ||
| package doesn't break. It also gives users a list of people to | ||
| contact for help when someone reports a build error with the package. |
There was a problem hiding this comment.
I think this is a great explanation of the multiple reasons why someone would want to be notified of any change to a recipe, and have that codified. However, I can't help wondering if this might be better as two directives: maintainers and watchers. I can certainly imagine that someone interested only in keeping track of changes that might break their software stack might not want themselves considered "maintainers" to the point of being a contact point for help in case of breakage. The separately-named directives would be treated the same way from the point of view of the review machinery, but would not be considered a point of contact for support. Thoughts?
There was a problem hiding this comment.
@alalazo I don't think "users who rely on a piece of software and want to ensure the package doesn't break," are necessarily people who want to be on a, "...list of people to contact for help when someone reports a build error with the package." While both groups of people should be notified and/or hit up for reviews when the PR comes in, I don't think they should be conflated to that degree.
There was a problem hiding this comment.
Personally I don’t think the increased complexity of having two lists is worth it. Conda-forge also uses a single maintainers field. The people who rely on a piece of software and want to be notified of a change are also likely to have encountered the same build problem and know how to fix it
There was a problem hiding this comment.
In my opinion maintainers will be a short and moderately stable group of people that commit some time to keep a recipe in a good state and can be contacted for review if that recipe is touched. This is directly related to the state of maintenance of the recipe and thus it seems right to have them listed in package.py.
People that want to just watch a package might be a lot more and a lot less stable - this is to say that having those people subscribed to / unsubscribed from notifications via issuing a PR doesn't feel right. Just my 2 cents.
There was a problem hiding this comment.
@adamjstewart @alalazo That's perfectly fine, just not what I got from the wording.
No description provided.