Add hpa reviewers #131650
Add hpa reviewers #131650
Conversation
Signed-off-by: Omer Aplatony <omerap12@gmail.com>
| - gjtempleton | ||
| - mwielgus | ||
| - omerap12 | ||
| - raywainman |
There was a problem hiding this comment.
The same comment applies here as the one I wrote in #131292 (comment)
There was a problem hiding this comment.
Huh? This is reviwers not approvers.
this just defines who gets assigned for the initial review.
There was a problem hiding this comment.
I think in a state of inadequate approver capacity we cannot afford to be strict about the number of primary reviews before even signing up to be assigned reviews
they should meet the membership requirements however.
https://github.com/kubernetes/community/blob/master/community-membership.md#requirements-1
There was a problem hiding this comment.
they should meet the membership requirements however.
There are similar requirements for reviewer, see https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer
There was a problem hiding this comment.
I linked to and commented on them above.
There was a problem hiding this comment.
Member for at least 3 months
yes must be done.
Primary reviewer for at least 5 PRs to the codebase
Reviewed or merged at least 20 substantial PRs to the codebase
See comment above.
Knowledgeable about the codebase
Sponsored by a subproject approver
With no objections from other approvers
of course, responses awaited
Done through PR to update the OWNERS file
May either self-nominate, be nominated by an approver in this subproject, or be nominated by a robot
that would be this, self-nominated
There was a problem hiding this comment.
I think in a state of inadequate approver capacity we cannot afford to be strict about the number of primary reviews before even signing up to be assigned reviews
I'm not saying we have to be super strict with the numbers, but I do feel some prior reviewer experience is good to have.
There was a problem hiding this comment.
Totally agree, @soltysh. Just to note - everyone included in that PR is already a VPA approver, so they’ve got reviewer experience.
For HPA, it’s a bit tougher. Development has been pretty quiet, and there are quite a few needs-triage issues and PRs without active approvers - like #127050 and #127394.
Given the current situation, maybe it makes sense to be a bit flexible here?
There was a problem hiding this comment.
The above is reasonable approach, and we can count that towards the requirements.
There was a problem hiding this comment.
Confirmed looking at https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/OWNERS
| - gjtempleton | ||
| - mwielgus | ||
| - omerap12 | ||
| - raywainman |
There was a problem hiding this comment.
The above is reasonable approach, and we can count that towards the requirements.
|
LGTM label has been added. Git tree hash: 93ed78e3c82698022d0aeb7d3b50d7dd0012b691
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: omerap12, soltysh 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 |
|
/triage accepted |
|
Flake #131545 |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Add hpa reviewers
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: