如何开启OpenStack社区贡献之路

作者：九州云99Coud  陈星

OpenStack作为第二大开源社区，拥有众多代码贡献者。但是，对于刚刚接触OpenStack，想要了解OpenStack源码，并且想为OpenStack的开发贡献自己的一份力量时，经常会不知从何下手。本文便是针对此类情况，介绍如何加入社区，如何提交commit，如何review代码等问题展开的。
1签订ICLA参与社区贡献前，需要签订ICLA协议。进入docs.openstack.org网站,在Contributor Guides下找到并点击“OpenStack Infrastructure User Manual ”。如图1所示 图1进入图2所示页面，点击图中所标注的链接。 图2
页面跳转至图3所示位置，依次打开图中所标注的链接。按照网站说明进行注册。需要注意的是，在注册launchpad时，要使用所在公司的邮箱，便于社区统计各公司的贡献数据。当然，如果你是自由职业者或者所在公司没有在社区上注册，则可随意使用一个邮箱。
图3当完成以上四步后，便可以看到OpenStack Individual Contributor License Agreement（ICLA）已验证。如图4所示。
2
上传自己的SSH 密钥这里请参考github上的操作说明: https://help.github.com/articles/generating-ssh-keys
3
配置Git Bashgit config --global user.name "XXX"git config --global user.email XXX@XXXXXX.com此处填写要与gerrit账户一致。
4
安装git-review具体步骤请参考https://www.mediawiki.org/wiki/Gerrit/git-review
5
下载源码库作为刚刚接触社区的同学，建议先在openstack-manuals项目上下手，一方面可以借此熟悉openstack。同时，在进行社区贡献，验证bug时，促使自己动手操作，增加运维经验。先从github上下载源代码，以OpenStack社区手册openstack-manuals为例：git clone git://github.com/openstack/openstack-manuals.gitcd openstack-manualsgit review -s首先会确保能使用你的ssh key登录gerrit，默认使用当前git环境变量配置的用户，否则，会提示输入gerrit用户名，可以通过这个链接查看gerrit用户名。成功后，会在openstack-manuals目录下生成一个.gitreview目录最新代码：git checkout mastergit pull新建分支，如果是blueprint，分支名是“bp/BP-NAME”，其中的BP-NAME是在launchpad上bp的名称;如果是修复bug，分支明是“bug/BUG-NUMBER”，其中BUG-NUMBER可以在bug页面上找到：git checkout -b BRANTCH-NAME
6
commit注意，在每提交一个新的commit之前，请先确保代码是最新的。执行下面两条命令更新库。git checkout mastergit pull提交代码前，还需要对openstack-manuals目录下的.git文件夹内的两个文件进行修改。
此处红色标注的字，请在下图所示的页面中查看，第一次需要生成一个密码，可以重复生成，请尽量选择使用没有特殊字符的密码，由大小写字母加数字的密码即可。若是在nova项目下，请修改***标注的openstack-manuals为nova即可。
vim hooks/commit-msg此文件为自动生成并添加commit的changeID。复制粘贴以下内容
一个示例：在通过按照社区安装文档上的指导进行部署OpenStack后，登录dashboard，会提示一系列错误，找到修复办法是需要禁用掉三层的各个服务。首先需要在配置文档界面提交bug,该页面应该是你增加修复办法的页面。如下图所示：
会进入提交bug界面：
1、  先用尽量简洁的话概述自己所遇到的bug.2、  点击Check ,看是否已经有人提出过，系统会搜索所有已提出的bug,然后列出与你所提出的可能相同的bug，逐个检查是否与你将要提出的bug一致，若一致，请勿再次提出，若没有，则点击继续提出bug。3、  填写更多信息，若标题已足以表情达意，则无需赘述。4、  点击Submit Bug Report.进入bug详细信息界面，如下图所示：
回到终端界面，新建一个分支，并且修改如图中所示的doc/install-guide/source/horizon-install.rst文件。命令如下:新建一个分支，为了便于以后好查看，分支名可以使用bug/ BUG-NUMBER来命名，实现一个BP也是同理。git checkout -b bug/1526721修改文件。vim doc/install-guide/source/horizon-install.rst将要添加的修复bug配置根据OpenStack社区文档格式要求进行修改，添加。然后保存。cd doc/install-guide/source/git add horizon-install.rstgit commit会跳转至commit message编辑界面。在单独的一行中写summary(小于50个字符)，然后空一行，第二段进行详细的描述。再空一行，最后一段如果是实现bp或修复bug，需注明：blueprint BP-NAMEClose-bug: #BUG-NUMBER如下图所示。
详细的代码提交信息，参见：https://wiki.openstack.org/wiki/GitCommitMessages然后提交代码，申请reviewgit commit --amendgit review需要注意的是，如果进行了第二次修改，再次git commit时，请务必加上—amend参数，除非你想覆盖掉之前的patch。
7
review下面介绍如何评审他人提交的代码。如图5所示，点击所标注的链接，进入还未合并的代码页面，如图6所示。
图5 图6图6中，需要说明的是最后的三列，”CR”指的是最新的一个reviewer评审的情况，”+1“指代码没什么问题，看起来不错；”-1”表示代码有些问题，需要代码提交者进一步修改；”+2”会显示成绿色的小勾，一般的社区人员无法给出，是由社区的Core给出的，表示代码满足合并的要求，当有两个不同的项目下的Core都给出了”+2”，workflow（也就是最后一列的”W”）+1后，该Commit才会进入合并阶段。当给出CR显示为”-2”时，该Commit就可以被Abandoned掉了。“V”列表示verified，代码测试。每当一个新的Commit或者原有的Commit有新的修改后，会由Jenkins自动测试，若测试通过，则为”+1”，若有一项失败，便会显示为”-1”。“W“列表示workflow，”+1”时在上文已经介绍过，这里不在重复，当”W”列为”-1”时，表示代码不能进入合并阶段。点击一个subject，进入gerrit评审界面。
点击图中箭头指示的链接，进入代码展示界面。
图中绿色区域便是我们新添加进去的配置，与原来的文件内容不同的，背景都会是绿色高亮显示。当你评审一处绿色区域的代码后，发现了有需要改正的地方，可以按住鼠标左键划动你觉得需要修改的地方，然后按c键，就会弹出代码评论编辑对话框：
在评审了所有绿色区域的代码后，便可以点击右上角的绿色的向上箭头回到gerrit评审界面，点击Reply进行评审给分。 各分值得含义在上面我已经介绍过了，如果你要-1，请说明理由。请不要在别人已经指出需要修改，并且给出了code review-1的地方再次提出-1，此为刷榜行为，会严重影响公司国际形象。这样，我们就完成了一个review。

转载于:https://blog.51cto.com/99cloud/1745082