前言：无意间开了个定阅号，算给自己找了一个写博客的理由和动力吧；怎么也得对得起关注的小伙伴们。其实想了想，还真不知道写点什么；现在的文章很多，除了公司的推广软文，还有一些使用者记录的一些笔记。不过好像没什么人写关于开发者的文章，索性先写一段时间关于Kuberentes开发的文章，包括一些社区的讨论和一些issue的fix过程；希望可以帮到国内的Kuberentes开发者。
社区里最简单的 PR 应该就是typo；typo可以帮助熟悉社区的流程，也是刷数据的利器！刚进Mesos社区那会儿很少fix typo：在产品线上呆时间长了，认为只有P1/S1才有意义。见仁见智吧，至少熟悉流程还是必要的。这里拿typo开始说，看看在k8s提交PR大概需要哪些过程和涉及人员、角色。
第一步：找typo
怎么找typo？这个看你自己的本事了。这里主要想介绍一下Kuberentes社区的几个repo：
kubernetes/kubernetes: Kubernetes的主社区，kube-apiserver, kube-controller-manager, kubelet等的代码都在这里；有时候社区里会说upstream，一般也指这个。但由于这里的代码太多，而且github的权限控制粒度较粗，各个组件正在拆分出去，以独立的repo管理。拆分的原则有相应的讨论及文档，后继再写文章详细介绍
kuberentes/community: 这里记录了kuberentes 各个feature的设计文档，新的proposal也需要以PR的形式在这里提交。例如之前提交的 “Policy based resource sharing”，现在还没有review完。
kubernetes/kubernetes.github.io: 这里是https://kubernetes.io的代码，以Markdown语法编写。
kuberentes下面还有很多其它的repo，比如 ingress, dashboard等。不过 kubernetes/kuberentes 的流程是最用的，但也是最长、最麻烦的。后面的描述都以kuberenetes/kubernetes中的typo为基础描述。
第二步：创建PR
创建PR (pull request) 时并不一定要创建issue，特别是像typo这样的小PR。至于如何创建PR，请参考github 的相关文档。
如果要为某个issue创建PR, 需要在PR的描述里填写 fixes #issue_num。这样 PR 在 merge后issue会“自动”关闭。
PR创建后，k8s机器人会做以下几件事：
- 检查创建者的linux function cla；如果没签，就按它的提示做就可以了
- 在相应OWNER列表里选取一个人做为reviewer
- 如果是kubernetes member，则启动CI来检查PR，例如UT, e2e test；如果不是kuberentes member ，则需要一个member 帮忙启动相应ci
待CI没有问题后，可以ping 相应的reviewers来检查代码了。
第三步：分支合并
一般typo都没有什么comments，只是别再引入typo就行。在reviewer认为可以后，需要标 lgtm (look go to me) 标签；同时需要该模块的approver标记 approve 标签。两个标签都有了以后，就可以等待合并了。
代码的合并也是由k8s机器人完成的，可以在 http://submit-queue.k8s.io/#/queue 看到等待合并的PR。在合并之前，k8s机器人也会自动重新跑ci以保证代码没有问题。
以上三步差不多就可以将typo提交到主干上。其中大部分工作都有k8s机器人自动完成，比如分配reviewer；相关的人员也只是reviewer 和 approver两个。这里有些细节没办法展开讲，比如k8s里的角色。后面的文章再把这些细节慢慢展开吧。
comments powered by