Join GitHub today
Krew plugin criteria #152
as you all know, krew-index currently has no criteria to apply for accepting or rejecting plugins. This creates friction for both contributors and maintainers:
So I put up this draft for plugin criteria to get the discussion going. It is an opinionated crude first draft and probably misses a lot of things. But maybe it helps nevertheless. Let me know what you think.
cc @garethr because you wanted to tune in
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: corneliusweig
If they are not already assigned, you can assign the PR to them by writing
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing
Thanks for taking charge here. We definitely need this document, so this is gonna be a long PR.
Styling-wise: I feel like if you can put the Guidances right next to the situations (maybe markdown table, maybe just a sub-bullet point) it would be easier to read and leave review-comments.
garethr left a comment
Thanks for kicking the conversation off. I had a good conversation at KubeCon about plugins with @ahmetb too.
Left some inline comments.
I think the main observation is to make it clear about what the criteria are for. The title says "Krew plugin" but I don't think this is defined anywhere explicitly. This should make a clear distinction between the Krew index or Krew plugins and the open Kubectl plugins.
I'd also suggestion merging this with the Naming guide, as really the naming guide is probably a subset of these criteria.
Thanks for doing the html migration, looks like we need to use full html i.e.
I want to capture an additional criteria about plugins being more broadly usable to most Kubernetes users, but this is hard to measure and evaluate.
One of them feels right, where the other one doesn’t, and this is hard to measure.
In the end, what you suggest always boils down to: how large is the userbase for setup XY. But even if we come up with an agreement what should be the acceptable number of users, how would we measure that in practice?
Hence, I'm more with @garethr here who brought up the brew philosophy: if somebody maintains it, it's fine. (Of course it still needs to match the other to-be-determined criteria).
What I could imagine to work is a whitelist of well-known k8s projects for which plugins may be submitted. For example: knative, istio, linkerd, tekton, jenkins-x, rook.io, and so on. Of course such a list needs to be curated and be kept up to date. By default, all incubating CNCF projects should be on that list too.