Move Kui repo to kubernetes-sigs

[paulcastro]

New Repo, Staging Repo, or migrate existing

Change ownership of existing repo from github.com/IBM

• https://github.com/IBM/kui

Requested name for new repository

• kubernetes-sigs/kui

Which Organization should it reside

kubernetes-sigs

If not a staging repo, who should have admin access

• starpit
• myan9

If not a staging repo, who should have write access

• team: sig-cli-maintainers
• team: kui-maintainers

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

• starpit
• myan9
• mark-nc

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

• starpit
• myan9
• mark-nc

What should the repo description be

A hybrid command-line/UI development experience for cloud-native development

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

this is a subproject for sig-cli called Kui

Approvals

The sig-cli already tracks kui as a subproject as described in this KEP https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2257-kui

Additional context for request

• We assume we can update sigs.yaml after repo creation?

/cc @soltysh @starpit

[nikhita]

/sig cli

/assign @soltysh @eddiezane @pwittrock
for approval

[soltysh]

👍 from my end, I'm positive that other leads are on -board since this was discussed during sig-cli multiple times in the past.

[nikhita]

@soltysh thanks for the ack!

@paulcastro since the repo needs to be migrated, can you ensure that the repo meets the requirements listed here - https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#rules-for-donated-repositories?

Once that's done, please ping me here again and I can help with the migration. :)

[pwittrock]

+1

[starpit]

@nikhita Thanks for the help! I think we have all of the rules engaged with the following exceptions:

1. the CLA bot is set up, but we are still waiting for @thelinuxfoundation to accept the user invitation; this is needed to fully enable the bot

2. prow: is my understanding correct that we will need to find a cluster to host this? or is their provision for piggybacking multiple projects onto a single prow?

[nikhita]

the CLA bot is set up, but we are still waiting for @thelinuxfoundation to accept the user invitation; this is needed to fully enable the bot

@starpit -- the linuxfoundation bot will not accept the invitation. Once the repo is migrated over, CLA checks will automatically be enabled on all PRs.

prow: is my understanding correct that we will need to find a cluster to host this? or is their provision for piggybacking multiple projects onto a single prow?

A single prow instance is used for all k8s projects. https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md has more details on how to use it.

---

@starpit @paulcastro There are few more things we need to get out of the way before we can migrate the repo.

• Boilerplate headers - can you please add copyright boilerplate headers to all files in the repo? https://git.k8s.io/kubernetes/hack/boilerplate/boilerplate.go.txt has the templates.

• All contributors need to have signed the CLA before we can migrate the repo. Unfortunately, the following people have not signed the CLA.

  • @abdonrd
  • @jesusprubio
  • @ruanxianzhi
  • @ImgBotApp
  • @joshuaauerbachwatson
  • @ydarias
  • @sushmarchandran
  • @hanqiuzh
  • @rvennam
  • @ujibang
  • @avhhh
  • @kant
  • @nirvana-flame
  • @LouisStAmour

Note: if your name is listed above, could you please sign the CNCF CLA so that we can migrate the Kui repo to Kubernetes? Instructions on how to sign the CLA can be found here. Thank you! :)

---

@starpit @paulcastro We'll need to wait for a few weeks to see if any of the folks listed below sign the CLA. If there are outliers who have not signed the CLA, you can either:

1. remove the file if that's possible - Migrate krew & krew-index to kubernetes-sigs #599 (comment)
2. add a NOTICE file - Migrate DirectXMan12/k8s-prometheus-adapter to kubernetes-sigs #2182 (comment)

[joshuaauerbachwatson]

Hi. I am listed as someone who needs to sign a new CLA. I long ago stopped being an active contributor to the kui core and would prefer not to go through these additional steps if it can be avoided. It sounds like you can just delete me as a contributor.

[LouisStAmour]

Signed :)

[abdonrd]

Signed!

[ujibang]

Signed! Andrea Di Cesare Partner at Soft*Instigate* <https://softinstigate.com/> Via Copernico 38, 20125 Milano (Italy) Mobile: +39 329 737 6417 Skype: ujibang The company behind *REST*Heart <https://restheart.org>, the Runtime for Microservices with Instant Data API on MongoDB Il giorno gio 4 feb 2021 alle ore 17:07 Abdón Rodríguez Davila < notifications@github.com> ha scritto:

…

Signed! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUO2VZ2EBTZD5Z7R3LFTYDS5LA4RANCNFSM4WR7NRDQ> .

[jesusprubio]

Signed!

[myan9]

@nikhita, thanks for the help! We've done the Copyright header and Notice file. We're investigating on travis status check via prow. Currently Kui is using travis-ci for testing, so we want to configure prow to merge a PR when travis tests pass. Does the following configuration code against test-infra/config/prow/config.yaml look good to you? Does required_status_checks mean that prow will check the travis test result as long as the repo is travis enabled? We looked a couple of repos that specify travis status check in the config.yaml, but somehow prow merge PRs even if those repo no longer use travis. That's why we're a bit confused... Thank you!

  kui:
       required_status_checks:
           contexts:
           - continuous-integration/travis-ci

[nikhita]

Does the following configuration code against test-infra/config/prow/config.yaml look good to you?

Yes, this looks good!

Does required_status_checks mean that prow will check the travis test result as long as the repo is travis enabled? We looked a couple of repos that specify travis status check in the config.yaml, but somehow prow merge PRs even if those repo no longer use travis.

Yes, as long as travis is enabled in your repo and you specify required_status_checks in config.yaml, PRs will merge only if the travis check is green.

As a project, we encourage writing prow jobs instead of using travis so I'd recommend looking at migrating to prow entirely. You can find the docs here.

[myan9]

@nikhita, thanks for the clarification! We'll continue the prow work once the PR is merged. We just finished the last round of cleaning up Copyright headers. Could you check if we're g2g? Thanks a lot!

[nikhita]

@myan9 just a few more things, sorry :(

• Looking at chore: add Kubernetes Copyright headers to all files kubernetes-sigs/kui#7062, it looks like some boilerplate headers have the format Copyright 2017-19 The Kubernetes Authors. Copyright headers in k8s specify only a single year. I'd recommend copying over the boilerplate verify scripts to help with this. Here's an example - Add script to verify boilerplate header kubernetes-sigs/cluster-api-provider-digitalocean#111

• It looks like there are still several contributors who have not signed the CNCF CLA (Move Kui repo to kubernetes-sigs #2461 (comment)). @swinslow 👋 from a legal standpoint, do you think it would be okay to add a NOTICE file to migrate this repo over?

[swinslow]

@nikhita 👋

One thing I note looking at the contributors listed above (setting aside those who have signed since then) is that several appear to work for existing k8s contributors like IBM, Red Hat and VMware. If someone from those companies can confirm here that their contributions can be treated as covered under those companies' existing signed CNCF CLAs, that would take care of them.

For the remainder, if there isn't a path forward to getting them to sign the CLA, then yes, I believe the project's practice is to include a NOTICE file with the language that was used recently for another repo in a similar situation.

[starpit]

@swinslow thanks for the help. We have I think a final list of CLA non-signers, and have added them to a NOTICE file as follows:

Submitted on behalf of a third-party: ImgBotApp “ImgBotApp”
Submitted on behalf of a third-party: Joshua “joshuaauerbachwatson” Auerbach
Submitted on behalf of a third-party: Yeray “ydarias” Darias
Submitted on behalf of a third-party: Darío “kant” Hereñú
Submitted on behalf of a third-party: Nirvana “nirvana-flam” Flame

In terms of contributions:

1. these are simple image optimizations, to reduce the size of files, and done by an automated bot
2. these contributions amount to a few lines of code that create a file if the thus-named file does not yet exist
3. are to .github template files, e.g. for new bug/new issue
   4 and 5) minor changes to the README.md

Will the NOTICE file suffice for these? Thanks!

[spiffxp]

/milestone v1.21

[swinslow]

Hi @starpit, yes, these sound like minor contributions, and given past practice I think it would be fine to proceed with listing them in the NOTICE file as you described. Thanks!

[nikhita]

@starpit @myan9 @mark-nc can you create an issue to apply for membership to the @kubernetes-sigs GitHub org? Only members can approve PRs once the repo has been migrated. Instructions are here - https://github.com/kubernetes/community/blob/master/community-membership.md#member

I think we're good to go after that 👍

[mark-nc]

@nikhita Do we open one PR for all three of us, or one PR for each? The link you provided also mentions @-ing two sponsors in the PR. Who are our sponsors?

[mark-nc]

Never mind.....discussed this with @starpit

[starpit]

Update: the three Kubernetes Memberships have been approved and accepted!

#2572
#2573
#2574

[nikhita]

@starpit Yay! If you can add me as an admin to the IBM/kui repo, I can help migrate it to k-sigs. :)

[starpit]

@nikhita done 👍

[nikhita]

@starpit I still don't see the Settings tab for the kui repo (admins should be able to see this) 🤔

Edit: worked with @starpit on slack to fix this

[nikhita]

Repo has been migrated - https://github.com/kubernetes-sigs/kui 🚀

@starpit @myan9 @mark-nc Thank you so much for your patience in getting this to the finish line!

I've also created two more PRs:

• Add GitHub teams for kui repo #2595 - to add GitHub teams to grant access
• sig-cli: add kui repo community#5656 - to add the repo to sigs.yaml

Once both PRs merge, we can close this issue.

[nikhita]

All PRs have merged and teams have been granted access. Closing.