Add New contributor summit notes
I took some notes during the New contributor summit notes. Here they are
This commit is contained in:
Julien Garcia Gonzalez
parent
92839e8631
commit
b148bbcab2
|
|
@ -0,0 +1,346 @@
|
||||||
|
# New kubernetes contributor workshop
|
||||||
|
|
||||||
|
Joining in the beginning was onboarding on a yacht
|
||||||
|
Now is more onboarding a BIG --Paquebot
|
||||||
|
|
||||||
|
Will be a Hard schedule, and let's hope we can achieve everything
|
||||||
|
Sig-contributor-experience -> from Non-member contributores to Owner
|
||||||
|
|
||||||
|
## SIG presentation
|
||||||
|
|
||||||
|
- SIG-docs & SIG-contributor-experience: **Docs and website** contribution
|
||||||
|
- SIG-testing: **Testing** contribution
|
||||||
|
- SIG-\* (*depends on the area to contribute on*): **Code** contribution
|
||||||
|
|
||||||
|
**=> Find your first topics**: bug, feature, learning, community development and documentation
|
||||||
|
|
||||||
|
Table exercise: Introduce yourself and give a tip on where you want to contribute in Kubernetes
|
||||||
|
|
||||||
|
|
||||||
|
## Communication in the community
|
||||||
|
|
||||||
|
Kubernetes community is like a Capybara: community members are really cool with everyone and they are from a lot of diffrenet horizons.
|
||||||
|
|
||||||
|
- Tech question on Slack and Stack Overflow, not on Github
|
||||||
|
- A lot of discussion will be involve when GH issues and PR are opened. Don't be frustrated
|
||||||
|
- Stay patient because there is a lot of contribution
|
||||||
|
|
||||||
|
When in doubt, **ask on Slack**
|
||||||
|
|
||||||
|
Other communication channels:
|
||||||
|
|
||||||
|
- Community meetings
|
||||||
|
- Mailing lists
|
||||||
|
- @ on Github
|
||||||
|
- Office Hour
|
||||||
|
- Kubernetes meetups https://www.meetup.com/topics/kubernetes
|
||||||
|
|
||||||
|
on https://kubernetes.io/community, there is the schedule for all the SIG/Working group meeting.
|
||||||
|
If you want to join or create a meetup. Go to **slack#sig-contribex**
|
||||||
|
|
||||||
|
## SIG - Special Interest Group
|
||||||
|
|
||||||
|
Semi-autonomous teams:
|
||||||
|
- Own leaders & charteers
|
||||||
|
- Code, Github repo, Slack, mailing, meeting responsibility
|
||||||
|
|
||||||
|
### Types
|
||||||
|
|
||||||
|
[SIG List](https://github.com/kubernetes/community/blob/master/sig-list.md)
|
||||||
|
|
||||||
|
1. Features Area
|
||||||
|
- sig-auth
|
||||||
|
- sig-apps
|
||||||
|
- sig-autoscaling
|
||||||
|
- sig-big-data
|
||||||
|
- sig-cli
|
||||||
|
- sig-multicluster
|
||||||
|
- sig-network
|
||||||
|
- sig-node
|
||||||
|
- sig-scalability
|
||||||
|
- sig-scheduling
|
||||||
|
- sig-service-catalog
|
||||||
|
- sig-storage
|
||||||
|
- sig-ui
|
||||||
|
2. Plumbing
|
||||||
|
- sig-cluster-lifecycle
|
||||||
|
- sig-api-machinary
|
||||||
|
- sig-instrumentation
|
||||||
|
3. Cloud Providers *(currently working on moving cloudprovider code out of Core)*
|
||||||
|
- sig-aws
|
||||||
|
- sig-azure
|
||||||
|
- sig-gcp
|
||||||
|
- sig-ibmcloud
|
||||||
|
- sig-openstack
|
||||||
|
4. Meta
|
||||||
|
- sig-architecture: For all general architectural decision
|
||||||
|
- sig-contributor-experience: Helping contributor and community experience
|
||||||
|
- sig-product-management: Long-term decision
|
||||||
|
- sig-release
|
||||||
|
- sig-testing: In charge of all the test for Kubernetes
|
||||||
|
5. Docs
|
||||||
|
- sig-docs: for documentation and website
|
||||||
|
|
||||||
|
## Working groups and Subproject
|
||||||
|
|
||||||
|
From working group to subproject.
|
||||||
|
|
||||||
|
for stuff really specific. Eg. `Helm` Belong to *SIG-apps* but dedicated subporject
|
||||||
|
|
||||||
|
**=> Tools, Goals or Area**
|
||||||
|
|
||||||
|
Move faster than SIG
|
||||||
|
|
||||||
|
- wg-app-def
|
||||||
|
- wg-apply
|
||||||
|
- wg-cloud-provider
|
||||||
|
- wg-cluster-api
|
||||||
|
- wg-container-identity
|
||||||
|
- ...
|
||||||
|
|
||||||
|
## Tour des repositories
|
||||||
|
|
||||||
|
Everything will be refactored (cleaning, move, merged,...)
|
||||||
|
|
||||||
|
### Core repository
|
||||||
|
- [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)
|
||||||
|
|
||||||
|
### Project
|
||||||
|
|
||||||
|
- [kubernetes/Community](https://github.com/kubernetes/Community): Kubecon, proposition, Code of conduct and Contribution guideline, SIG-list
|
||||||
|
- [kubernetes/Features](https://github.com/kubernetes/Features): Features proposal for future release
|
||||||
|
- [kubernetes/Steering](https://github.com/kubernetes/Steering)
|
||||||
|
- [kubernetes/Test-Infra](https://github.com/kubernetes/Test-Infra): All related to test except Perf
|
||||||
|
- [kubernetes/Perf-Tests](https://github.com/kubernetes/Perf-Tests):
|
||||||
|
|
||||||
|
### Docs/Website
|
||||||
|
|
||||||
|
- website
|
||||||
|
- kubernetes-cn
|
||||||
|
- kubernetes-ko
|
||||||
|
|
||||||
|
### Developer Tools
|
||||||
|
|
||||||
|
- sample-controller*
|
||||||
|
- sample- apiserver*
|
||||||
|
- code-generator*
|
||||||
|
- k8s.io
|
||||||
|
- kubernetes-template-project: For new github repo
|
||||||
|
|
||||||
|
### Staging repositories
|
||||||
|
|
||||||
|
Mirror of core part for easy vendoring
|
||||||
|
|
||||||
|
### SIG repositories
|
||||||
|
|
||||||
|
- release
|
||||||
|
- federation
|
||||||
|
- autoscaler
|
||||||
|
|
||||||
|
### Cloud Providers
|
||||||
|
|
||||||
|
No AWS
|
||||||
|
|
||||||
|
### Tools & Products
|
||||||
|
|
||||||
|
- kubeadm
|
||||||
|
- kubectl
|
||||||
|
- kops
|
||||||
|
- helm
|
||||||
|
- charts
|
||||||
|
- kompose
|
||||||
|
- ingress-nginx
|
||||||
|
- minikube
|
||||||
|
- dashboard
|
||||||
|
- heapster
|
||||||
|
- kubernetes-anywhere
|
||||||
|
- kube-openapi
|
||||||
|
|
||||||
|
### 2nd Namespace: Kubernetes-sigs
|
||||||
|
|
||||||
|
Too much places for Random/Incubation stuff.
|
||||||
|
No working path for **promotion/deprecation**
|
||||||
|
|
||||||
|
In future:
|
||||||
|
1. start in Kubernetes-sigs
|
||||||
|
2. SIGs determine when and how the project will be **promoted/deprecated**
|
||||||
|
|
||||||
|
Those repositories can have their own rules:
|
||||||
|
- Approval
|
||||||
|
- Ownership
|
||||||
|
- ...
|
||||||
|
|
||||||
|
## Contribution
|
||||||
|
|
||||||
|
### First Bug report
|
||||||
|
|
||||||
|
```
|
||||||
|
- Bug or Feature
|
||||||
|
|
||||||
|
- What happened
|
||||||
|
|
||||||
|
- How to reproduce
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
### Issue for specification
|
||||||
|
|
||||||
|
Most of k8s change start with an issue:
|
||||||
|
|
||||||
|
- Feature proposal
|
||||||
|
- API changes proposal
|
||||||
|
- Specification
|
||||||
|
|
||||||
|
### From Issue to Code/Docs
|
||||||
|
|
||||||
|
1. Start with an issue
|
||||||
|
2. Apply all appropriate labels
|
||||||
|
3. cc SIG leads and concerned devs
|
||||||
|
4. Raise the issue at a SIG meeting or on mailing list
|
||||||
|
5. If *Lazy consensus*, submit a PR
|
||||||
|
|
||||||
|
### Required labels https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md
|
||||||
|
|
||||||
|
#### On creation
|
||||||
|
- `sig/\*`: the sig the issue belong too
|
||||||
|
- `kind/\*`:
|
||||||
|
- bug
|
||||||
|
- feature
|
||||||
|
- documentation
|
||||||
|
- design
|
||||||
|
- failing-test
|
||||||
|
|
||||||
|
#### For issue closed as port of **triage**
|
||||||
|
|
||||||
|
- `triage/duplicate`
|
||||||
|
- `triage/needs-information`
|
||||||
|
- `triage/support`
|
||||||
|
- `triage/unreproduceable`
|
||||||
|
- `triage/unresolved`
|
||||||
|
|
||||||
|
#### Prority
|
||||||
|
|
||||||
|
- `priority/critical-urgent`
|
||||||
|
- `priority/important-soon`
|
||||||
|
- `priority/important-longtem`
|
||||||
|
- `priority/backlog`
|
||||||
|
- `priority/awaiting-evidence`
|
||||||
|
|
||||||
|
#### Area
|
||||||
|
|
||||||
|
Free for dedicated issue area
|
||||||
|
|
||||||
|
- `area/kubectl`
|
||||||
|
- `area/api`
|
||||||
|
- `area/dns`
|
||||||
|
- `area/platform/gcp`
|
||||||
|
|
||||||
|
#### help-wanted
|
||||||
|
|
||||||
|
Currently mostly complicated things
|
||||||
|
|
||||||
|
#### SOON
|
||||||
|
|
||||||
|
`good-first-issue`
|
||||||
|
|
||||||
|
## Making a contribution by Pull Request
|
||||||
|
|
||||||
|
We will go through the typical PR process on kubernetes repos.
|
||||||
|
|
||||||
|
We will play there: [community/contributors/new-contributor-playground at master · kubernetes/community · GitHub](https://github.com/kubernetes/community/tree/master/contributors/new-contributor-playground)
|
||||||
|
|
||||||
|
1. When we contribute to any kubernetes repository, **fork it**
|
||||||
|
|
||||||
|
2. Do your modification in your fork
|
||||||
|
```
|
||||||
|
$ git clone git@github.com:jgsqware/community.git $GOPATH/src/github.com/kubernetes/community
|
||||||
|
$ git remote add upstream https://github.com/kubernetes/community.git
|
||||||
|
$ git remote -v
|
||||||
|
origin git@github.com:jgsqware/community.git (fetch)
|
||||||
|
origin git@github.com:jgsqware/community.git (push)
|
||||||
|
upstream git@github.com:kubernetes/community.git (fetch)
|
||||||
|
upstream git@github.com:kubernetes/community.git (push)
|
||||||
|
$ git checkout -b kubecon
|
||||||
|
Switched to a new branch 'kubecon'
|
||||||
|
|
||||||
|
## DO YOUR MODIFCATION IN THE CODE##
|
||||||
|
|
||||||
|
$ git add contributors/new-contributor-playground/new-contibutor-playground-xyz.md
|
||||||
|
$ git commit
|
||||||
|
|
||||||
|
|
||||||
|
### IN YOUR COMMIT EDITOR ###
|
||||||
|
|
||||||
|
Adding a new contributors file
|
||||||
|
|
||||||
|
We are currently experimenting PR process in the kubernetes repository.
|
||||||
|
|
||||||
|
$ git push -u origin kubecon
|
||||||
|
```
|
||||||
|
|
||||||
|
3. Create a Pull request via Github
|
||||||
|
4. If needed, sign the CLA to make valid your contribution
|
||||||
|
5. Read the `k8s-ci-robot` message and `/assign @reviewer` recommended by the `k8s-ci-robot`
|
||||||
|
6. wait for a `LTGM` label from one of the `OWNER/reviewers`
|
||||||
|
7. wait for approval from one of `OWNER/approvers`
|
||||||
|
8. `k8s-ci-robot` will automatically merge the PR
|
||||||
|
|
||||||
|
`needs-ok-to-test` is used for non-member contributor to validate the pull request
|
||||||
|
|
||||||
|
## Test infrastructure
|
||||||
|
|
||||||
|
> How bot toll you when you mess up
|
||||||
|
|
||||||
|
At the end of a PR there is a bunch of test.
|
||||||
|
2 types:
|
||||||
|
- required: Always run and needed to pass to validate the PR (eg. end-to-end test)
|
||||||
|
- not required: Needed in specific condition (eg. modifying on ly specific part of code)
|
||||||
|
|
||||||
|
If something failed, click on `details` and check the test failure logs to see what happened.
|
||||||
|
There is `junit-XX.log` with the list of test excuted and `e2e-xxxxx` folder with all the component logs.
|
||||||
|
To check if the test failed because of your PR or another one, you can click on the **TOP** `pull-request-xxx` link and you will see the test-grid and check if your failing test is failing in other PR too.
|
||||||
|
|
||||||
|
If you want to retrigger the test manually, you can comment the PR with `/retest` and `k8s-ci-robot` will retrigger the tests.
|
||||||
|
|
||||||
|
## SIG-Docs contribution
|
||||||
|
|
||||||
|
Anyone can contribute to docs.
|
||||||
|
|
||||||
|
### Kubernetes docs
|
||||||
|
|
||||||
|
- Websites URL
|
||||||
|
- Github Repository
|
||||||
|
- k8s slack: #sig-docs
|
||||||
|
|
||||||
|
### Working with docs
|
||||||
|
|
||||||
|
Docs use `k8s-ci-robot`. Approval process is the same as for any k8s repo
|
||||||
|
In docs, `master` branch is the current version of the docs. So always branch from `master`. It's continous deployment
|
||||||
|
For a specific release docs, branch from `release-1.X`.
|
||||||
|
|
||||||
|
## Local build and Test
|
||||||
|
|
||||||
|
The code: [kubernetes/kubernetes]
|
||||||
|
The process: [kubernetes/community]
|
||||||
|
|
||||||
|
### Dev Env
|
||||||
|
|
||||||
|
You need:
|
||||||
|
- Go
|
||||||
|
- Docker
|
||||||
|
|
||||||
|
|
||||||
|
- Lot of RAM and CPU and 10 GB of space
|
||||||
|
- best to use Linux
|
||||||
|
- place you k8s repo fork in:
|
||||||
|
- `$GOPATH/src/k8s.io/kubernetes`
|
||||||
|
- `cd $GOPATH/src/k8s.io/kubernetes`
|
||||||
|
- build: `./build/run.sh make`
|
||||||
|
- Build is incremental, keep running `./build/run.sh make` til it works
|
||||||
|
- To build variant: `make WHAT="kubectl"`
|
||||||
|
- Building kubectl on Mac for linux: `KUBE_*_PLATFORM="linux/amd64" make WHAT "kubectl"`
|
||||||
|
|
||||||
|
there is `build` documentation there: https://git.k8s.io/kubernetes/build
|
||||||
|
|
||||||
|
### Testing
|
||||||
|
there is `test` documentation there: https://git.k8s.io/community/contributor/guide
|
||||||
Loading…
Reference in New Issue