Add review policy #19988
Add review policy #19988
Conversation
|
Also see #19987 (comment) |
ahrtr
force-pushed
the
review_policy_20250520
branch
2 times, most recently
from
fb5985d to
fbaf539
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted filessee 35 files with indirect coverage changes @@ Coverage Diff @@
## main #19988 +/- ##
==========================================
- Coverage 68.82% 68.16% -0.66%
==========================================
Files 424 424
Lines 35762 35762
==========================================
- Hits 24612 24378 -234
- Misses 9728 9950 +222
- Partials 1422 1434 +12 Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
Let's discuss in this PR. Which policy you disagree? |
|
Hi @fuweid @ivanvc @jmhbnz @serathius @siyuanfoundation let's focus on the policies proposed in this PR. It's based on current status. In future when we integrate K8s's auto merge utility, we can revisit & update this guide by then. Please share your thoughts, thx |
| - Approvals should come from a maintainer, reviewer, or submodule owner familiar with the relevant code or area. | ||
| - If there’s disagreement, maintainers should discuss and agree before merging. | ||
|
|
||
| ## Exceptions for Less Impactful PRs |
There was a problem hiding this comment.
From my perspective, exceptions make the process harder to follow. Sometimes, flaky test cases can make it even worse. We have several active reviewers and maintainers, so requiring two approvals seems reasonable to me.
There was a problem hiding this comment.
so requiring two approvals seems reasonable to me.
Yes, it's true.
exceptions make the process harder to follow.
That's the reason why I provide a list of examples below.
There was a problem hiding this comment.
exceptions make the process harder to follow.
For test, it's indeed sometime harder to follow, but let's provide some flexiblities. At least, it won't break the production code.
There was a problem hiding this comment.
Sometimes, flaky test cases can make it even worse.
Good point! Removed tests from the list.
ahrtr
force-pushed
the
review_policy_20250520
branch
from
fbaf539 to
bd3ddc6
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr, jmhbnz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
This PR only needlessly split the discussion. |
There was a problem hiding this comment.
Thanks @ahrtr !! More clarity with the review process is better. As @jmhbnz mentioned moving it to existing triage_prs.md or https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#get-your-pull-request-reviewed sounds good.
ahrtr
force-pushed
the
review_policy_20250520
branch
from
bd3ddc6 to
2230691
Compare
Signed-off-by: Benjamin Wang <[email protected]>
ahrtr
force-pushed
the
review_policy_20250520
branch
from
2230691 to
c0132db
Compare
|
@ahrtr: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.
cc @fuweid @ivanvc @jmhbnz @serathius @siyuanfoundation @spzala