-
Notifications
You must be signed in to change notification settings - Fork 67
Consider archiving this repo #360
Comments
i'm +1 to archive subprojects that are not active or never took off. we don't have a requirement to say e.g. "10 months of subproject inactivity means archival", but to me it seems the tempo has slowed down here. last open PR is from April with zero comments: unless the maintainer roster has a strong argument i propose a lazy consensus archival for the 16th of Sept 2024. |
/lgtm |
1 similar comment
/lgtm |
notified the ML about this ticket: |
+1 to decommission |
We are actively using this project. Currently we have a fork of it and have upgraded to the latest version of K8s. We would welcome becoming a maintainer. |
@x85446 could you provide some more context? What use cases are you using this project for? Also, at first sight, upgrading a k8s version alone can't probably make this provider usable with Cluster API, so I assume you are only using some part of it as a library, but I might be wrong. Last but not least, IMO to qualify as a community project, It would be great to have some more users/maintainers from a few companies. Do you know someone else using it? |
i personally think it's too late for that and we shouldn't surface a group that forked the project but did not actively participate in maintaining it when it was needed. also interested to know more about the use case, though. |
Lol. Well, our company did not exist at the time :) (we are not as large as VMWare or Apple and we don't have the luxury of having many open-source developers :). We just very recently forked the project b/c we are building a multi-tenancy K8s solution. We plan on putting our entire project back under an Apache 2 license. We are very thankful for the contributions of everyone and the project as it is. Either way we will continue to move forward with our own work. If you all are not interested or feel it's not appropriate for it to be under the K8s SIG umbrella we entirely understand and would take no offense. |
Well here is our fork: https://github.com/IzumaNetworks/cluster-api-provider-nested Right now everything we did was to get it to run on 1.30 - which is in Our focus will be on improving virtualcluster security and decreasing the amount of overhead. If we don't receive additional guidance we will keep maintaining this fork. Once again, thanks to everyone! @ Fei Guo @christopherhein @m-messiah and the many others... |
@neolit123: Closing this issue. In response to this:
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-sigs/prow repository. |
If I look at this repo, it seems that unfortunately this idea never took off:
According to @vincepri , who is the person I know with more info about this topic, the nested provider can be archived.
I quite agree
Opinions?
cc @neolit123 @justinsb @vincepri from a SIG PoV
cc @christopherhein @charleszheng44 @Fei-Guo @zhuangqh from the maintainer list
If there is agreement, prior art for archiving a repo: kubernetes/org#5013
The text was updated successfully, but these errors were encountered: