Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add sjenning and mrunalp to approvers and reviewers #505

Merged

Conversation

rphillips
Copy link

Add mrunalp and sjenning to the approvers and reviewers.

cc @mfojtik @sjenning @mrunalp @deads2k

OWNERS Outdated
@@ -9,6 +9,8 @@ filters:
- mfojtik
- marun
- tnozicka
- mrunalp
- sjenning

# approvers are limited to the team that manages rebases and pays the price for carries that are introduced
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rphillips This comment suggest against addition as approvers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These individuals have had approval rights within Origin to perform approvals on this section of code before. Not allowing Seth or Mrunal approval rights here will greatly slow down the team, since it will be dependent on non-owners of the kubelet code to approve and review changes.

Was there a discussion on slack or the dev list about approval rights here?

Copy link

@sttts sttts Jan 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not allowing Seth or Mrunal approval rights here will greatly slow down the team, since it will be dependent on non-owners of the kubelet code to approve and review changes.

The solution is to build kubelet out of another repo/branch. It is what networking team and oc team do. As long as o/k is the build source, we have this rule and are very hesitant to weaken it. We understand the pain though, totally.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not allowing Seth or Mrunal approval rights here will greatly slow down the team

Where has this actually happened?

I would claim that approvers here do a very good job to react quickly to approval requests. If approval is rejected, there should be good reasons. I would personally be curious where you had the impression in the past where we did not live up to the standard.

@deads2k
Copy link

deads2k commented Jan 4, 2021

These individuals have had approval rights within Origin to perform approvals on this section of code before. Not allowing Seth or Mrunal approval rights here will greatly slow down the team, since it will be dependent on non-owners of the kubelet code to approve and review changes.

Given than maintenance of the fork is not done by @mrunalp or by @sjenning or by their teams, I'm inclined to leave the approval of patches outside of their domain in upstream kubernetes (owners files from kube are honored) to the teams who actually maintain the code. The origin codebase of old was much larger and the need to approve changes across areas other than the fork of kubernetes forced a wider set of approvers.

@deads2k
Copy link

deads2k commented Jan 4, 2021

/hold

based on above.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 4, 2021
OWNERS Outdated
@@ -18,6 +20,8 @@ filters:
- mfojtik
- marun
- tnozicka
- mrunalp
- sjenning

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Controversial question: will @mrunalp and @sjenning do Kubernetes rebases in the future? I am totally fine with more reviewers here. I am not fine with adding approvers (authority) without having the responsibility for the rebase.

/hold

@rphillips rphillips force-pushed the add_sjenning_mrunal branch 3 times, most recently from 83a8b95 to 19f1da6 Compare January 5, 2021 14:56
@sttts
Copy link

sttts commented Jan 5, 2021

As agreed in Slack.

/lgtm
/approve

@openshift-ci-robot openshift-ci-robot added lgtm Indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jan 5, 2021
@sttts
Copy link

sttts commented Jan 5, 2021

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 5, 2021
@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jan 5, 2021
@deads2k
Copy link

deads2k commented Jan 5, 2021

/lgtm
/approve

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, rphillips, sttts

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 5, 2021
@openshift-bot
Copy link

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit b1e9f0d into openshift:master Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants