added review a PR guide#8258
Conversation
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
Tests analyticsTotal tests: Action takenFound 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccComputeFirewallPolicyRule_multipleRules |
|
Tests failed during RECORDING mode: Please fix these to complete your PR |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
| weight: 11 | ||
| --- | ||
|
|
||
| # Review a PR |
There was a problem hiding this comment.
There are different expectations for maintainer and contributor PRs (self-service / community), should we call them out separately in some way? In particular I'm thinking of:
- I don't give more than a passing glance to release notes for a maintainer PR, and trust they've written them correctly. For contributor PRs I've got to author them myself.
- For contributors I've got to wait until all tests are green until clicking approve. For maintainers, I'm generally fine approving if I'm satisfied with the code as-written and tests are most of the way (80-90%) there, even if they're currently failing.
There was a problem hiding this comment.
I agree that we have different expectations for maintainer and contributor PRs, but I think this review guide is more like a general checklist that users/ reviewers should follow to (self-)review a PR. We should have all these boxes checked before merging a PR no matter it's a maintainer or contributor PR. Although for maintainer PRs, it's more like the PR author's responsibility to ensure all these steps have been checked. I could call out that that it's author's responsibility (or whoever click the merge button) to ensure that the PR passed all the checks on this list for maintainer PRs. What's your thought?
There was a problem hiding this comment.
FWIW I would prefer not to call out that we might have separate standards for maintainers since that is not relevant to most of the people who would read this page and might confuse folks
There was a problem hiding this comment.
Ehh, fair enough- the page is doing double-duty as a maintainer and contributor guide in that case, which may leave ambiguities for maintainers.
Tests analyticsTotal tests: Action takenFound 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccComputeFirewallPolicyRule_multipleRules |
|
Tests failed during RECORDING mode: Please fix these to complete your PR |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
Tests analyticsTotal tests: Action takenFound 2 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccComputeFirewallPolicyRule_multipleRules|TestAccContainerAwsNodePool_BetaBasicHandWritten |
|
|
|
Any thoughts on different responsibilities as mentioned in #8258 (comment)? |

fixes b/288626199
If this PR is for Terraform, I acknowledge that I have:
make testandmake lintin the generated providers to ensure it passes unit and linter tests.Release Note Template for Downstream PRs (will be copied)