As mention therein, I am happy for kube-rs to outlive my historically fleeting interest for things.
But, moving kube-rs to cncf under the kubernetes org comes with a bunch of pros and cons.

PROS:

• we become official, people trust us, we seem supported we get listed
• we avoid getting into a pointless competition with a naive, generated client under kubernetes/
• competition is incoming; judging by their tone, they will go ahead with the above without us
• gives the project future safety from @clux's disconnection from the world / potential delayed-onset insanity
• speculative: paves the way for tighter integration with sig-apimachinery ?
• more free CI infrastructure - github actions is free for us anyway
• In the case where a security change necessitates and API change, you will get notification during the embargo period and have more time to fix it.

CONS:

• need kubernetes bots and automation proposal: chubaofs to incubation stage cncf/toc#586 (not for CNCF)
• potential need to donate codegen - DCO/CLA audit cncf/toc#606 (not for CNCF)
• Needs a CLA (only for kubernetes orgs)
• being marked as official is arguably pointless when the rust community will treat us as the official client anyway
• Your major/minor releases will likely be tied to k8s releases - likely plays in with Add John Hillegass to CONTRIBUTORS.md cncf/toc#508
• Being tied to a foundation might limit our ability to stay afloat with sponsorship (linux foundation might take cuts)

Will create separate issues for the CONS under a new donation label so we can discuss specifics in a less cluttered way. This issue can be used for general points, and what we think about this.

A donation would follows this kubernetes process. No longer true. We are following the CNCF sandbox approach now.