🌱 Clarify that controller-runtime is not a kubebuilder subproject#3185
🌱 Clarify that controller-runtime is not a kubebuilder subproject#3185k8s-ci-robot merged 1 commit intokubernetes-sigs:mainfrom
Conversation
This used to be true in the very beginning of the projects but isn't anymore today, there are different people working on these projects.
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
approved
alvaroaleman
changed the title
| Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/). | ||
|
|
||
| controller-runtime is a subproject of the [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) project | ||
| in sig apimachinery. |
There was a problem hiding this comment.
I believe the way we maintain the projects — whether or not they share maintainers — doesn’t define whether they are sub-projects of Kubebuilder. We may have the same maintainers or not, and that’s totally fine. IMO: This isn’t about OWNER aliases, but rather about the purpose and scope of the tools and projects themselves.
However, changes in controller-runtime should still take into account their impact on Kubebuilder — a tool maintained under the Kubernetes SIGs that builds on top of controller-runtime, promotes its usage, provides documentation, and helps users understand how to use it effectively.
While controller-runtime and controller-tools can technically be used independently of Kubebuilder, it’s Kubebuilder that has been the primary driver of their adoption in practice.
So, I’d like to suggest we rephrase it to something like:
Kubebuilder is built on top of the controller-runtime and controller-tools libraries, providing a higher-level scaffolding tool to help developers create Kubernetes APIs more easily.
There was a problem hiding this comment.
That is already in the readme: https://github.com/kubernetes-sigs/controller-runtime/blame/d8b679322d5cc466d12301b8875c42040fd29e46/README.md#L6-L8
We will keep on considering kubebuilders needs, this is just to clarify that these are independent projects.
There was a problem hiding this comment.
That is already in the readme: https://github.com/kubernetes-sigs/controller-runtime/blame/d8b679322d5cc466d12301b8875c42040fd29e46/README.md#L6-L8
I see — that makes sense, and that’s great to hear! 🎉
I agree that controller-runtime and controller-tools can be used independently of Kubebuilder, so I’m totally fine with the clarification.
/lgtm
/approve
That said, Kubebuilder has also been actively documenting and promoting both libraries over the years. We'd really love to receive help, feedback, and suggestions from the maintainers of controller-runtime and controller-tools to improve Kubebuilder’s scaffolding, documentation, and overall user experience.
We truly want to work together to ensure the success of all the projects and provide the best experience for the community. 🙌
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. DetailsGit tree hash: 257bfa15a4369e46579e51a33ab1f2ca37d18cd8 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, camilamacedo86 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3 participants
This used to be true in the very beginning of the projects but isn't anymore today, there are different people working on these projects.