When I first implemented spackbot, I added a guard in the code that prevents maintainers from being notified on PRs that modify 100+ packages. The idea was that PRs that affect that many files are often automated changes like license updates where we don't actually need to notify anyone.
Recently, we've had a few very large PRs where I would like to bypass this guard and notify maintainers:
The first modifies 300+ packages, while the latter two actually modify < 100 files and should work, but aren't working. So this is also a bug report that @spackbot maintainers doesn't seem to be working correctly.
I think the ideal behavior would be for PRs modifying 50+ packages to not add maintainers by default, but if someone runs @spackbot maintainers it should add maintainers regardless of how many files are modified. Does this seem reasonable? Is this doable?
Also, GitHub has a limit on the number of people you can mention in a single comment (seems to be 50) so we may need to break these into multiple comments. Although over time more people will be added as triage and will get assigned as reviewers instead of being included in the comment, so maybe this is a non-issue. It's a corner case at best.
When I first implemented spackbot, I added a guard in the code that prevents maintainers from being notified on PRs that modify 100+ packages. The idea was that PRs that affect that many files are often automated changes like license updates where we don't actually need to notify anyone.
Recently, we've had a few very large PRs where I would like to bypass this guard and notify maintainers:
depends_onspack#28131The first modifies 300+ packages, while the latter two actually modify < 100 files and should work, but aren't working. So this is also a bug report that
@spackbot maintainersdoesn't seem to be working correctly.I think the ideal behavior would be for PRs modifying 50+ packages to not add maintainers by default, but if someone runs
@spackbot maintainersit should add maintainers regardless of how many files are modified. Does this seem reasonable? Is this doable?Also, GitHub has a limit on the number of people you can mention in a single comment (seems to be 50) so we may need to break these into multiple comments. Although over time more people will be added as triage and will get assigned as reviewers instead of being included in the comment, so maybe this is a non-issue. It's a corner case at best.