Org: Migrate https://github.com/adelina-t/hyperkube to kubernetes org

Created on 31 Oct 2019  路  11Comments  路  Source: kubernetes/org

New Repo, Staging Repo, or migrate existing

Migrate existing repository: https://github.com/adelina-t/hyperkube

Requested name for new repository

hyperkube

Which Organization should it reside

kubernetes

If not a staging repo, who should have admin access

Release Engineering subproject owners: @justaugustus, @tpepper, @calebamiles

If not a staging repo, who should have write access

@adelina-t

If not a staging repo, who should be listed as approvers in OWNERS

Added in https://github.com/adelina-t/hyperkube/pull/1.

If not a staging repo, who should be listed in SECURITY_CONTACTS

Added in https://github.com/adelina-t/hyperkube/pull/1.

What should the repo description be

"hyperkube is an all-in-one binary for the Kubernetes server components."

What SIG and subproject does this fall under in sigs.yaml

This is part of the Release Engineering subproject for SIG Release

Approvals

Self-approve as SIG Release Chair and Release Engineering subproject owner.
Relevant threads:

Authoritative requirements are here: https://git.k8s.io/community/github-management/kubernetes-repositories.md

tl;dr (but really you should read the linked doc, this may be stale)

  • If this is a core repository, then sig-architecture must approve
  • If this is a SIG repository, then this must follow the procedure spelled out
    in that SIG's charter

/assign @nikhita @cblecker @mrbobbytables
cc: @adelina-t @dims @feiskyer @PatrickLang @markyjackson-taulia @dghubble @kubernetes/release-engineering
/sig release
/area release-eng

aregithub-repo do-not-merghold sirelease

All 11 comments

@justaugustus: The label(s) area/release-eng cannot be applied. These labels are supported: api-review, community/discussion, community/maintenance, community/question, cuj/build-train-deploy, cuj/multi-user, platform/aws, platform/azure, platform/gcp, platform/minikube, platform/other

In response to this:

New Repo, Staging Repo, or migrate existing

Migrate existing repository: https://github.com/adelina-t/hyperkube

Requested name for new repository

hyperkube

Which Organization should it reside

kubernetes

If not a staging repo, who should have admin access

Release Engineering subproject owners: @justaugustus, @tpepper, @calebamiles

If not a staging repo, who should have write access

@adelina-t

If not a staging repo, who should be listed as approvers in OWNERS

Added in https://github.com/adelina-t/hyperkube/pull/1.

If not a staging repo, who should be listed in SECURITY_CONTACTS

Added in https://github.com/adelina-t/hyperkube/pull/1.

What should the repo description be

"hyperkube is an all-in-one binary for the Kubernetes server components."

What SIG and subproject does this fall under in sigs.yaml

This is part of the Release Engineering subproject for SIG Release

Approvals

Self-approve as SIG Release Chair and Release Engineering subproject owner.
Relevant threads:

Authoritative requirements are here: https://git.k8s.io/community/github-management/kubernetes-repositories.md

tl;dr (but really you should read the linked doc, this may be stale)

  • If this is a core repository, then sig-architecture must approve
  • If this is a SIG repository, then this must follow the procedure spelled out
    in that SIG's charter

/assign @nikhita @cblecker @mrbobbytables
cc: @adelina-t @dims @feiskyer @PatrickLang @markyjackson-taulia @dghubble @kubernetes/release-engineering
/sig release
/area release-eng

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/test-infra repository.

@justaugustus Just to dot the i's and cross the t's, can you send an email to the sig-arch ML (or mention a link here, in case I missed it!) asking for explicit approval to move this repo to the @kubernetes org? Currently, the linked sig-arch ML thread doesn't seem to have approval to move this repo to @kubernetes.

Also, the issue https://github.com/kubernetes/kubernetes/issues/81760 says (https://github.com/kubernetes/kubernetes/issues/81760#issuecomment-538199652):

As mentioned earlier, i have https://github.com/dims/hyperkube and looks like @adelina-t will be surfacing another repository as well. We can pick either one ( preferably @adelina-t 's) and request a new repository under kubernetes-sigs.

@nikhita --

@justaugustus Just to dot the i's and cross the t's, can you send an email to the sig-arch ML (or mention a link here, in case I missed it!) asking for explicit approval to move this repo to the @kubernetes org? Currently, the linked sig-arch ML thread doesn't seem to have approval to move this repo to @kubernetes.

Ahhh, forgot about the additional SIG Arch approval for kubernetes org repos. Will send a note to the ML shortly.

Also, the issue kubernetes/kubernetes#81760 says (kubernetes/kubernetes#81760 (comment)):

As mentioned earlier, i have https://github.com/dims/hyperkube and looks like @adelina-t will be surfacing another repository as well. We can pick either one ( preferably @adelina-t 's) and request a new repository under kubernetes-sigs.

https://github.com/adelina-t/hyperkube is the new repo. :)

@adelina-t There are a few more things we'll need to do pre-transfer after getting approval:

As mentioned earlier, i have https://github.com/dims/hyperkube and looks like @adelina-t will be surfacing another repository as well. We can pick either one ( preferably @adelina-t 's) and request a new repository under kubernetes-sigs.

https://github.com/adelina-t/hyperkube is the new repo. :)

Ah, I meant that the comment says the repo should move to k-sigs. :stuck_out_tongue:

But I'll wait for sig-arch approval. Thanks for staying on top of this, @justaugustus! :)

@adelina-t There are a few more things we'll need to do pre-transfer after getting approval:

Fixed up in https://github.com/adelina-t/hyperkube/pull/1.

Ah, I meant that the comment says the repo should move to k-sigs.

Figured it would be easier to manage the team (Release Engineering) without dupe-ing it in k-sigs, but I'm easy either way! :)

/hold

Thanks @justaugustus

let's give a chance for folks to chime in today at sig-arch code-org meeting.

I'm not in favor of an official kubernetes-sigs project that intentionally uses k8s.io/kubernetes as a library, running counter to the guidance we've consistently given.

I'd be in favor of resolving the desired approach in the original issue (https://github.com/kubernetes/kubernetes/issues/81760) before proceeding here

/hold
Explicit hold from me too.. even if we move forward with this, I want to talk about the code ownership trail here, because this was originally kubernetes code to begin with.

I think we've settled on a different approach (https://github.com/kubernetes/kubernetes/issues/81760), so closing this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Raffo picture Raffo  路  3Comments

szuecs picture szuecs  路  3Comments

ibrasho picture ibrasho  路  3Comments

aravindputrevu picture aravindputrevu  路  3Comments

RA489 picture RA489  路  3Comments