代码提交流程
1. pull代码创建分支
# 如果本地没有clone过上游代码，需要clone代码
git clone github.com/openvswitch/ovs
pushd ovs
# 拉取最新的代码
git fetch origin
# 基于最新的上游代码创建一个开发分支
git checkout -b feature_X origin/master
popd2. 编写代码。
- 尽量参考已有代码的规范：空行、缩进、空格、注释等。
- 如果代码修改涉及到新的测试例，也需要添加测试例。
3. 编写代码后需要运行测试。
3.1 运行测试之前需要先对代码进行编译，如果需要测试内核模块还需要编译内核模块。
# 通常boot.sh运行一次之后，第二次编译就不用再次运行了。
# 如果做了这些操作，最好重新运行boot.sh:
# - 版本发生变化，比如从master切换到自研2.14版本
# - 对.m4, .in文件进行了修改
# - 添加了新的文件
./boot.sh
# 通常./configure也只运行一次就行，第二次编译不用再执行
# 下面的情况需要重新运行boot.sh:
# - 要对编译选项进行修改
# - ./boot.sh被重新执行
./configure
# or
# ./configure --with-linux=/lib/modules/$(uname -r)/build
# -j 表示并行数，用多个core进行编译能大大提高编译速度
make -j 323.2 单元测试，单元测试支持并发，推荐使用并发(-j)能大大提高速度
# 查看单元测试list
make check TESTSUITEFLAGS=--list
# 运行所有单元测试
make check TESTSUITEFLAGS=-j6
# 只运行一个或几个单元测试例，通过list的号码指定测试例
make check TESTSUITEFLAGS='123 477-484'
# 根据关键字查找测试例然后运行
make check TESTSUITEFLAGS='-k ovsdb'3.3 datapath测试，可以测试用户态的datapath也可以测试kernel datapath。datapath的测试不支持并发，且运行datapath测试之前需要停掉运行中ovs进程。
# userspace datapath test
make check-system-userspace
# kernel datapath test
# this install kmod and run tests
make check-kmod4. 代码本地commit
编写完代码后需要对代码进行commit，一次commit后可能还会继续修改，修改了之后需要继续commit。代码commit的一个原则：用一个commit解决一个问题，尽量不在一个commit解决多个问题。
# 首次commit需要通过 -s 参数进行签名
git commit -s # first commit
# commit msg 最好根据下面的格式编写
# - 首行指明修改的模块、简要描述修改目的。首行长度尽量50字符，其他行72字符
# - 首行之后需要空一行
# - 描述问题，如果问题复杂可以详细描述，如果问题简单一句话描述
# - 继续描述我们这个patch解决问题的思路，以及一些注意事项
# 非首次commit，且不希望记录上次commit和本次commit的差别。
# 使用--amend覆盖上次commit，这样可以避免多个commit解决一个问题
git commit --amend
# 如果我们在开发阶段要进行第二次commit，但又想保留第一次的commit则不用--amend选项
git commit # second commit
git commit # third commit, ...
# 但在把代码提交社区之前需要对我们的多次commit进行合并
# - 以第一次commit的*上一个*commit为基础进行rebase
# - 保留(pick)第一个commit，其他的commit压缩(squash)进第一个commit
git rebase -i first_commit_id^5. 生成patch
patch内容其实就是咱们commit的diff，邮件发出去之后别人可以根据diff看到咱们的改动。也可以把这个diff apply到他们本地代码。除了diff通常还包含一些其他少量信息。我们可以通过`git format-patch`命令生成patch。通常我们只需要生成一个patch进行提交，如果我们有多个patch，而这些patch之间有依赖性我们则需要一次生成多个patch，这些patch在同一个series里面。review的人会根据先后顺序review series中的patch。
# 生成单个patch，把patch输出到 ../upcall-patchs目录下
git format-patch -1 -v1 -o ../upcall-patchs/
# 生成一个patch series，包含3个commit。
# 生成后我们会看到4个patch文件，其中有一个序号000的patch
# 是用来对patch series进行描述的
git format-patch -3 -v1 --thread --cover-letter -o ../upcall-patchs/
# 经过一轮review我们对代码进行了修改，且通过commit --amend本地提交了代码。
# 这时需要重新生成patch v2
git format-patch -3 -v2 --thread --cover-letter -o ../upcall-patchs/
# 检查patch合规性
utilities/checkpatch.py ../upcall-patchs/v4-0002-tests-fix-packet-data-endianness.patch6. 通过邮件发送patch
发送邮件之前需要先[subscribe dev@openvswitch.org](mail.openvswitch.org/mailman/listinfo/ovs-dev) ，否则我们可能发不出去邮件，也收不到review的回复。
patch系统会记录邮件发送人，然后和commit里面的签名进行对比，如果对比不通过会有问题。所以要设置一下邮件的发件人，默认是邮箱。
比如我的commit 签名是: `xxx <xxx@abc.com>`，但是我的email发件人被识别为: `xxx@abc.com <xxx@abc.com>`。这样就有问题，可以在foxmail设置`发信名称`来配置发件人为 xxx。
根据如下信息依次发送series中的patch：
- 收件人: dev@openvswitch.org
- 主题: patch文件的`Subject`内容
- 邮件内容: patch文件subject以下的所有内容
邮件发送后几分钟就能在patchwork系统看到我们的提交了。
7. 回复邮件
别人review了我们的patch会提出一些问题，我们需要通过邮件进行回应。我看其他人回复的邮件，上一封邮件的内容会被`>`符号标记出来。我通过设置foxmail的模板实现了配置自动添加`>`符号，但功能还有缺陷(会加入很多额外的空行)。需要特别注意。
8. 引用
- github.com/openvswitch/ovs
- github.com/torvalds/linux/tree/master/net/openvswitch
- docs.openvswitch.org/en/latest/topics/testing/
- patchwork.ozlabs.org/project/openvswitch/list/
- mail.openvswitch.org/mailman/listinfo/
