community
community copied to clipboard
kubevirt
Add kubevirt/kubevirt approvers to this repository's OWNERS
What this PR does / why we need it: This repository lacks approvers, and most of the existing approvers aren't very active anymore.
As Kubevirt becomes more popular and active, and more design proposals are being introduced, we need more people to share the burden of reviewing and approving such proposals. This is especially important since https://github.com/kubevirt/community/pull/251 had landed.
Release note:
NONE
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign vladikr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
CCing all of the current approvers /cc @aburdenthehand @AlonaKaplan @cwilkers @davidvossel @fabiand @rmohr @vladikr /cc @fossedihelm @acardace
/lgtm
This really makes sense to move at a faster pace with design proposals.
/hold
What is the justification of kubevirt/kubevirt approvers to gain approval rights in this repository? Why not a different set of people? :)
Instead of increasing 1 core approver group with individuals, why can we not focus on the decentralized approach in order to increase our bandwidth: See #288
cc @lyarwood
tl;dr Before simply adding more approvers, let us please fix the process to make this process more scaleable.
/hold
What is the justification of kubevirt/kubevirt approvers to gain approval rights in this repository? Why not a different set of people? :)
Instead of increasing 1 core approver group with individuals, why can we not focus on the decentralized approach in order to increase our bandwidth: See #288
cc @lyarwood
tl;dr Before simply adding more approvers, let us please fix the process to make this process more scaleable.
Hey @fabiand! I definitely support https://github.com/kubevirt/community/pull/288. As the PR suggests, proposals (or VEPs) would be introduced to https://github.com/kubevirt/enhancements. I thought that in the meantime, until this effort takes effect, more Kubevirt approvers could contribute in reviewing "legacy" design proposals.
After we move to kubevirt/enhancements, I guess it would still makes sense that k/k approvers will have approval right in this repo, which I assume will mostly revolve around community guidelines.
Let's focus on #288 and move it forward.
Merging this pr is just making us loose our focus.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
/remove-lifecycle stale
@fabiand, see https://github.com/kubevirt/community/pull/319.
As said above, I do support https://github.com/kubevirt/community/pull/288 and try to promote it, but I don't think it should be a blocker for this PR. Would you consider unholding this and to get this in until your PR is merged?
+1 to what @iholder101 said.
As discussed in the community meeting, this repository lacks active approvers - this can be seen by the number of open pull requests without any activity from reviewer/approver side.
Let's focus on #288 and move it forward.
Merging this pr is just making us loose our focus.
@fabiand IMHO we should either split https://github.com/kubevirt/community/pull/288 into two (as suggested here) to move it forward, or get this in, or think of a different solution.
While we're not being able to converge into a solution, the problem gets bigger over time.
I think there's a pretty large consensus to get this PR in. I identify at least @dhiller @acardace @aburdenthehand @fossedihelm @alicefr @RamLavi @orelmisan @orenc1 @lyarwood as supporters for this approach, and we've already raised it in the community meeting and there was no pushback.
WDYT?
I don't believe there is consensus for mass addition of approvers, please refer to the lively discussion on https://groups.google.com/g/kubevirt-dev/c/uqN9cPRZAF8
What we need is few strong and active reviewers, such as the newly-nominated @jean-edouard . We need a plan to ensure that the existing approvers are active, and we need commitment to review and participate.
/hold
Pull requests that are marked with lgtm should receive a review
from an approver within 1 week.
After that period the bot marks them with the label needs-approver-review.
/label needs-approver-review
@iholder101: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| pull-community-make-generate | a39e9cb9c6c676b32b5045455df11f60815aef66 | link | true | /test pull-community-make-generate |
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.
@iholder101 Now that #362 is merged, can we close this?
Yes, thank you
/close
@iholder101: Closed this PR.
In response to this:
@iholder101 Now that #362 is merged, can we close this?
Yes, thank you
/close
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.