Skip to content
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

Merged
merged 4 commits into from
Aug 28, 2018
Merged

Conversation

seans3
Copy link
Contributor

@seans3 seans3 commented Aug 2, 2018

Implements the initial governance rules for SIG CLI.

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. sig/cli Categorizes an issue or PR as relevant to SIG CLI. labels Aug 2, 2018
@cblecker
Copy link
Member

cblecker commented Aug 2, 2018

@kubernetes/steering-committee
/committee steering

@k8s-ci-robot k8s-ci-robot added the committee/steering Denotes an issue or PR intended to be handled by the steering committee. label Aug 2, 2018
@spiffxp
Copy link
Member

spiffxp commented Aug 9, 2018

Hi @seans3 is this a redo of #2137? If so please close that one and point to here

@philips
Copy link
Contributor

philips commented Aug 10, 2018

cc @bgrant0607 SIG CLI review


SIG CLI code include command line tools and binaries for working with Kubernetes
API's. Examples of these binaries include: kubectl and kustomize.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

### 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.
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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:

  1. We won't mention kubeadm or kube-apiserver.
  2. We will keep the "Out of scope" statement as is.

If misunderstood, please let me know.

Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duplicated entry

Copy link
Contributor

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
Copy link
Member

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

Copy link
Contributor

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 code include command line tools and binaries for working with Kubernetes
API's. Examples of these binaries include: kubectl and kustomize.

### Out of scope
Copy link
Member

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?

Copy link
Contributor

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-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
Copy link
Member

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

@bgrant0607 bgrant0607 self-assigned this Aug 24, 2018
Copy link
Member

@bgrant0607 bgrant0607 left a 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.


### In scope

SIG CLI section in [sigs.yaml]
Copy link
Member

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.

### 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.
Copy link
Member

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.)


#### Code, Binaries and Services

SIG CLI code include command line tools and binaries for working with Kubernetes
Copy link
Member

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.

@philips
Copy link
Contributor

philips commented Aug 27, 2018

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
/approve
/hold

@k8s-ci-robot k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Aug 27, 2018
@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 27, 2018
@spiffxp
Copy link
Member

spiffxp commented Aug 27, 2018

/lgtm
from me too, FWIW

@philips
Copy link
Contributor

philips commented Aug 28, 2018

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 28, 2018
@k8s-ci-robot k8s-ci-robot merged commit ab4ada7 into kubernetes:master Aug 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. committee/steering Denotes an issue or PR intended to be handled by the steering committee. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/cli Categorizes an issue or PR as relevant to SIG CLI. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants