-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First version of SIG CLI Charter #2453
Conversation
@kubernetes/steering-committee |
cc @bgrant0607 SIG CLI review |
sig-cli/charter.md
Outdated
|
||
SIG CLI code include command line tools and binaries for working with Kubernetes | ||
API's. Examples of these binaries include: kubectl and kustomize. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please link to this: https://github.com/kubernetes/community/blob/master/sig-cli/README.md#subprojects
sig-cli/charter.md
Outdated
### Out of scope | ||
|
||
SIG CLI is NOT responsible for defining the Kubernetes API that it | ||
interfaces with. The Kubernetes API is the responsibility of SIG API Machinery. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is probably worthwhile to call out all of the other CLIs that SIG CLI doesn't oversee and why. For example kubeadm, kube-apiserver, etc, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The why being that these CLIs don't interact with the API I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's nothing stopping us from looking after them, but nobody reached out to us for so, that's why since none of us (sig participants) authored these we don't feel like owning them nor don't want to 'steal' other's work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a second note, I think that calling out what we don't oversee might be an overkill. IMO it's sufficient we clearly define ownership in the previous paragraph. The fact that API is being mentioned here is specifically to call out that we don't and never will change the API, that's sig-apimachinery responsibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not going to hold strong on this point. But, I do still believe it would be helpful to provide illustrative counter examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To recap, following Maciej's advice:
- We won't mention kubeadm or kube-apiserver.
- We will keep the "Out of scope" statement as is.
If misunderstood, please let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's helpful to lump all Kubernetes components, such as kube-apiserver, under "CLI".
I do think it's helpful to indicate that SIG CLI doesn't own all conceivable command-line tools within the project: kubeadm, kops, kompose, kubefed, etc.
I would add something like:
SIG CLI is not responsible for command-line tools built and maintained by other SIGs, such as kubeadm, which is owned by SIG Cluster Lifecycle.
(Just to include one example and not make it appear to be an exhaustive list.)
sigs.yaml
Outdated
label: cli | ||
leadership: | ||
chairs: | ||
- name: Maciej Szulik |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
duplicated entry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, there are chairs which are responsible for organizational issue with sig and leads which are responsible for technicalities. Sean and I are both chairs, on top of that Phil and I are tech-leads, which makes me deserve double entry 🥇
sigs.yaml
Outdated
- name: Maciej Szulik | ||
github: soltysh | ||
company: Red Hat | ||
- name: Sean Sullivan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like it might be better to make chair changes separately from the charter addition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just move this to separate commit, which should be sufficient.
sig-cli/charter.md
Outdated
SIG CLI code include command line tools and binaries for working with Kubernetes | ||
API's. Examples of these binaries include: kubectl and kustomize. | ||
|
||
### Out of scope |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it make sense to include some "Cross-cutting and Externally Facing Processes" aspects of how sig-cli collaborates with the sigs that own other binaries to improve command consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite sure what you mean by that?
sig-cli/charter.md
Outdated
|
||
|
||
[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md | ||
[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L487 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use of sigs.yaml with line number is not recommended by the latest changes in the charter template for a good reason that the number for sig section may not remain same - e0d60fd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Once my suggested changes are made I think this can be merged.
sig-cli/charter.md
Outdated
|
||
### In scope | ||
|
||
SIG CLI section in [sigs.yaml] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please link to the corresponding information in the sig-cli README instead.
sig-cli/charter.md
Outdated
### Out of scope | ||
|
||
SIG CLI is NOT responsible for defining the Kubernetes API that it | ||
interfaces with. The Kubernetes API is the responsibility of SIG API Machinery. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's helpful to lump all Kubernetes components, such as kube-apiserver, under "CLI".
I do think it's helpful to indicate that SIG CLI doesn't own all conceivable command-line tools within the project: kubeadm, kops, kompose, kubefed, etc.
I would add something like:
SIG CLI is not responsible for command-line tools built and maintained by other SIGs, such as kubeadm, which is owned by SIG Cluster Lifecycle.
(Just to include one example and not make it appear to be an exhaustive list.)
sig-cli/charter.md
Outdated
|
||
#### Code, Binaries and Services | ||
|
||
SIG CLI code include command line tools and binaries for working with Kubernetes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest "general-purpose command-line tools and binaries" as a way to distinguish these from the special-purpose tools built by other SIGs.
Since @pwittrock, @bgrant0607, and myself from the steering committee have all taken a look at this and #2137 I am going to approve this. However, if @jbeda would like to take one final look as one of the designated Steering reviewers I will hold until EOD. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: philips 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 |
/lgtm |
/hold cancel |
Implements the initial governance rules for SIG CLI.