Prepare Repo for a move to kubernetes-sigs

[adobley]

We've discussed in k8s slack and in the cluster-lifecycle-sigs meeting an intention to move this repo into kubernetes-sigs.

Assuming all interested parties approve this change there is some work we need to do to make it happen.

The k8s community lists out some rules for donated repositories that we need to ensure we satisfy. Some things must be done after a move, such as getting integrated with k8s CI.

I'll do my best to outline those requirements below so we can start to check them off. I'm fairly sure we already meet several of these requirements. I'll check those off as I validate them.

If there are any things that we may have missed, pease let me know and I'll ensure we keep track of them.

Pre-Move

• Must adopt the Kubernetes Code of Conduct
• All code projects use the Apache License version 2.0. Documentation repositories must use the Creative Commons License version 4.0.
• All OWNERS of the project must also be active SIG members.
  • I think we all are by contributing to a project that gets adopted by a SIG
• Must be approved by the process spelled out in the SIG's charter and a publicly linkable written decision should be available for the same.
• SIG must already have identified all of their existing subprojects and code, with valid OWNERS files, in sigs.yaml
• All contributors must have signed the CNCF Individual CLA or CNCF Corporate CLA
  • If (a) contributor(s) have not signed the CLA and could not be reached, a NOTICE file should be added referencing section 7 of the CLA with a list of the developers who could not be reached
• Boilerplate text across all files should attribute copyright as follows: "Copyright " if no CLA was in place prior to donation
• Licenses of dependencies are acceptable; project owners can ping @caniszczyk for review of third party deps
• Should contain template files as per the kubernetes-template-project.

Move

• Open an issue in github.com/kubernetes/org to move the repo (see REQUEST: Migrate kubernetes-sigs/cluster-api-addon-provider-helm kubernetes/org#3762 for a recent example)
  • For now all repos will live in github.com/kubernetes-sigs/<project-name>

Post-Move

• Additions of the standard Kubernetes header to code created by the contributors can occur post-transfer, but should ideally occur shortly thereafter.
  • Can we do this Pre-Move?
• Must contain the topic for the sponsoring SIG - e.g. k8s-sig-api-machinery. (Added through the Manage topics link on the repo page.)
• Adopt the CNCF CLA bot, merge bot and Kubernetes PR commands/bots. #148

[schrej]

I checked licenses. Dependencies only have MIT, ISC, BSD-3-Clause, BSD-2-Clause and Apache 2.0 according to make license-report (aka. go-licenses). All of those should be fine.

The next step in the process would be to open an issue in k/org, but we should probably talk to sig-cluster-lifecycle leads again before we do that.

@fabriziopandini @CecileRobertMichon (cc @vincepri)
I see that this was brought up in a SIG meeting (which I missed, unfortunately) already. Was this accepted as a project for sig-cluster-lifecycle? Would you like some further discussion in the next meeting, or is async sufficient?
Is there anything we should add/change before moving the repository (e.g. approvers; we'll add more after some people have joined kubernetes-sigs)?

Some context: In the IPAM proposal I suggested to have at least one provider in kubernetes-sigs that can serve as a reference. In addition VMware has put in quite a bit of work, and it would feel better if it didn't live in the telekom org.
We've had a brief discussion in one of the CAPI meetings on whether we want to include it in the core cluster-api repository. We ultimately decided against it, since releasing is a little easier, and to decouple them from CAPI releases, since frequency might be a little lower.

[fabriziopandini]

@schrej I'm +1 for the move, but given that folks got a little bit distracted by KubeCon, I suggest making a quick check via a ping to leads in the SIG channel

[CecileRobertMichon]

+1 from my side as well

This was brought up at the SIG office hours on 4/4 and there were no objections

[nikhita]

Additions of the standard Kubernetes header to code created by the contributors can occur post-transfer, but should ideally occur shortly thereafter.

Can we do this Pre-Move?

@adobley @schrej would it be possible for you to do this pre-move? 🙏

It's just cumbersome to track that the boilerplate has been added to all files after repo transfer. Easier if it's done pre-move.

[schrej]

@nikhita Boilerplate is in! There is a make verify-boilerplate (copied from k-sigs/cluster-api) make task in case you want to verify yourself, we don't have CI for it yet.

[adobley]

Seems like we checked off all the tasks and the repo is moved. Closing this, but feel free to reopen if I'm overlooking something.