-
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
# SIG CLI Charter | ||
|
||
This charter adheres to the conventions described in the [Kubernetes Charter README] and uses | ||
the Roles and Organization Management outlined in [sig-governance]. | ||
|
||
## Scope | ||
|
||
The Command Line Interface SIG (SIG CLI) is responsible for kubectl and | ||
related tools. This group focuses on command line tools and | ||
libraries to interface with Kubernetes API's. | ||
|
||
### In scope | ||
|
||
SIG CLI section in [sigs.yaml] | ||
|
||
#### 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 commentThe 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. |
||
API's. Examples of these binaries include: kubectl and kustomize. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
### Out of scope | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. Not quite sure what you mean by that? |
||
|
||
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 commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. To recap, following Maciej's advice:
If misunderstood, please let me know. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.) |
||
|
||
## Roles and Organization Management | ||
|
||
SIG CLI adheres to the Roles and Organization Management outlined in [sig-governance] | ||
and opts-in to updates and modifications to [sig-governance]. | ||
|
||
### Deviations from [sig-governance] | ||
|
||
- In addition to Technical Leads, SIG CLI defines Emeritus Leads. These former | ||
SIG CLI leaders *SHOULD* be available to provide historical perspective and | ||
knowledge. | ||
- SIG CLI defines the role of Test Health Maintainer. Contributors who have | ||
successfully completed one test on-call rotation within the last six months as | ||
shown in the test on-call schedule of the [Test Playbook] are included in this | ||
group. Test Health Maintainers are SIG CLI Members. | ||
|
||
### Subproject Creation | ||
|
||
Option 1: by [SIG Technical Leads](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md#L100) | ||
|
||
|
||
[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 commentThe 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 |
||
[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md | ||
[Test Playbook]: https://docs.google.com/document/d/1Z3teqtOLvjAtE-eo0G9tjyZbgNc6bMhYGZmOx76v6oM | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -492,23 +492,30 @@ sigs: | |
establishment of conventions for writing CLI commands, POSIX compliance, | ||
and improving the command line tools from a developer and devops user | ||
experience and usability perspective. | ||
charter_link: | ||
charter_link: charter.md | ||
label: cli | ||
leadership: | ||
chairs: | ||
- name: Maciej Szulik | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 🥇 |
||
github: soltysh | ||
company: Red Hat | ||
- name: Sean Sullivan | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more. I'd just move this to separate commit, which should be sufficient. |
||
github: seans3 | ||
company: Google | ||
leads: | ||
- name: Maciej Szulik | ||
github: soltysh | ||
company: Red Hat | ||
- name: Phillip Wittrock | ||
github: pwittrock | ||
company: Google | ||
- name: Tony Ado | ||
github: AdoHe | ||
company: Alibaba | ||
emeritus_leads: | ||
- name: Fabiano Franz | ||
github: fabianofranz | ||
company: Red Hat | ||
- name: Tony Ado | ||
github: AdoHe | ||
company: Alibaba | ||
meetings: | ||
- description: Regular SIG Meeting | ||
day: Wednesday | ||
|
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.