HPA development is not active

[sanposhiho]

/sig autoscaling
/cc @kubernetes/sig-autoscaling-misc

What

HPA's development has not been active recently.
It causes many PRs to struggle to get reviews, including some KEPs.
Essentially, this is the problem of lacking approvers in HPA.

Context (AFAIK)

Currently, @mwielgus is the only approver, but already left the sig-autoscaling chair, and I'm not sure if they're still willing to help in reviewing.
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/podautoscaler/OWNERS#L7
I know the step down doesn't always mean a stop working on things, but, in this case, actually the last review from them was more than 1 year ago.
https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+reviewed-by%3Amwielgus+is%3Aclosed

There are some minor changes made in HPA though, all of them are approved by someone else (root approvers), not stamps from sig-autoscaling.
https://github.com/kubernetes/kubernetes/commits/master/pkg/controller/podautoscaler

Also, @gjtempleton is trying to take over the position, and he's (only) a reviewer (not yet approver) apart from @mwielgus now.

• HPA - Add gjtempleton to reviewers #124607
• SIG Autoscaling - Update Leads #124661

Proposal

We're trapped in a vicious cycle; HPA development is not active because of the lack of reviewers/approvers, and no reviewer is newly born because HPA development is not active.

There's (probably, AFAIK) no other active person who is eligible for the reviewer/approver of HPA based on the official criteria.
But, we shouldn't keep the current situation, and I'd propose having some volunteers to join reviewers/approvers to break through (even if they're not officially eligible).

Regarding the approver, I cannot come up with any idea other than asking @gjtempleton to be an approver and start approving some PRs. (... I know they're also busy though)
Also, when I was doing the container-based HPA enhancement, I remember @pbarker also helped reviewing a lot, might be a good idea to ask them to join the reviewer list. (PRs, reviews) I can also help in being a reviewer too. (PRs, reviews)

[adrianmoisey]

This problem also applies to the VPA.
Myself (and a small group of others, @omerap12 being one of them) are trying to contribute to the VPA, in order to climb the ranks to become approvers. But it is catch 22, since the current approvers are very busy and can't dedicate much time to review.
For the moment we try review amongst ourselves, getting PRs into a good state. Then we batch up a bunch of PRs and ask the approvers to approve. This is mostly working well, but will take some time before we get to the point where we have more approvers.

I'm happy to turn my attention to the HPA too, but for now all I can offer is code review, no approval.

[omerap12]

This problem also applies to the VPA. Myself (and a small group of others, @omerap12 being one of them) are trying to contribute to the VPA, in order to climb the ranks to become approvers. But it is catch 22, since the current approvers are very busy and can't dedicate much time to review. For the moment we try review amongst ourselves, getting PRs into a good state. Then we batch up a bunch of PRs and ask the approvers to approve. This is mostly working well, but will take some time before we get to the point where we have more approvers.

I'm happy to turn my attention to the HPA too, but for now all I can offer is code review, no approval.

I agree with the above. I'm also willing to help, but I'm not very familiar with the HPA codebase yet (though I'd like to dive into it).

[DP19]

I can also volunteer some time here; I've become pretty familiar with the code when comparing it against a GKE issue we ran into here and also working on this bug (that's still waiting to be approved like you've mentioned)

[wzshiming]

This problem also bothered me, and I tried to push the from/to 0 feature of HPV but didn't get much progress

[soltysh]

This was brought to my attention as one of the steering members overlooking sig-autoscaling. I've started a conversation with current and past leads to ensure we can move forward and get us all in a situation that will ensure the SIG has the necessary power to approve code changes.

[sftim]

Is this possibly also relevant to SIG ContribEx?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sftim]

Myself (and a small group of others, @omerap12 being one of them) are trying to contribute to the VPA, in order to climb the ranks to become approvers. But it is catch 22, since the current approvers are very busy and can't dedicate much time to review.

BTW, SIGs can choose to treat opening of reasonable-looking PRs as grounds to accept a new reviewer.

Reviewers should try to make sure that the queue of ready-to-approve PRs is tidy and that only PRs genuinely ready for approval reach that stage.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten