2.6 如何贡献
我们相信，每一个走向软件开发这条路的开发者都不会仅仅满足于只在这个领域“打个酱油”，都会希望在Community里发出自己的声音，但是，作为一个弥漫着现实主义的开源社区，你能够发出的声音大小取决于你的贡献大小。
2.6.1 文档
如前文所述，完善的文档、文档与代码保持同步是影响软件可维护性的一个重要因素，而开发者大多是“勤于代码，懒于文档”的，但是为OpenStack完善文档也是提升自己贡献度的一种方式。
OpenStack的文档主要可以分为以下3类。
1.Wiki
OpenStack Wiki的内容包罗万象，既有一些HowTo指南，也有很多设计的细节，以及很多会议的信息和记录。
2.RST
开发者创建的RST文件位于各个项目代码树中的/doc/source/目录，也就是我们所谓的开发文档，如API说明。
3.DocBook
除了开发者，其他很多OpenStack用户，包括部署人员、管理人员、API用户等还使用DocBook创建了很多类似使用手册的文档，也有专门的一个OpenStack项目openstack-manuals用来负责相关的维护工作。
OpenStack的3类文档，除Wiki可以直接编辑以外，RST和DocBook文档的创建过程与代码提交的过程类似，区别是编写的格式及工具不同，如果我们把文档的格式要求也当成一种开发语言的话，那么区别只是代码开发使用的是Python，需要遵守Python的规则，而编写文档需要遵守相应文档格式的规则。
2.6.2 修补Bug
在进入一个新的领域时，常规的切入手段都是从简单的“修修补补”开始。作为新的OpenStack开发者，通常也是从修补Bug开始的。在这个修补Bug的过程中，我们应当对OpenStack的开发流程，代码的提交与管理过程有一个更为深入的理解。
1.寻找Bug
当然，修补Bug的前提是找到一个合适的Bug，有两种方法可以被采用：一种是在使用OpenStack的过程中被动等待Bug出现；另一种是主动出击，在现有已经提交的那些Bug中挑选一个合适的。
OpenStack已经对所有已提交的Bug按照项目进行了归类，比如，Nova的Bug列表如图2-14所示。
图2-14 Nova的Bug列表
在如图2-14所示的页面中，列出了目前已提交的所有Bug，我们可以单击页面右上角的“Report a bug”按钮来提交一个自己新发现的Bug，也可以打开Bug列表中的任何一个Bug进行查看。
提交新Bug的过程并不复杂，主要就是对Bug进行表述并确认是否有类似的Bug，困难的是如何去发现一个新的Bug。因此，对OpenStack新人来说，更为简单明了的方式就是从Bug列表中选择一个。
一个具体Bug的详细描述页面如图2-15所示，显示了这个Bug的优先级及当前状态等信息，在“Assigned to”中会显示该Bug是否已经被分配或认领，如果它显示的内容是“Unassigned”，也就是说该Bug处于无主状态，我们可以结合Bug的内容和自身的条件进行一番评估，如果合适的话，我们就可以将其分配给自己。
图2-15 一个具体Bug的详细描述页面
2.提交patch
认领一个合适的Bug只是第一步，接下来我们需要修补它，然后把我们的代码提交到Gerrit供人Review。
我们不能直接在Master分支上进行修补，而是要创建一个专门的分支来针对这个Bug进行修补，标准的流程应该是：
其中，“1335559”为一个Bug专属的ID，可以在Bug的详细描述页面上看到。需要注意的是，当我们使用git commit命令提交代码时，不要忘记在描述信息里加上“Closes-Bug：#1335559”。
通过git review命令将我们的patch成功提交到Gerrit之后，就可以在Gerrit上打开该Bug相应的页面来查看当前Review的过程并与其他开发者针对我们的修改进行互动。
2.6.3 增加Feature
通俗来说，Bug是漏洞，Feature是功能，一个惹人生厌，一个显得“高大上”。其实，有时Feature只是穿了“衣服”的Bug，如图2-16所示。
图2-16 Bug与Feature的区别
因此，与上节修补Bug的流程相比，本节的重点在于多出的那件“衣服”。
1.bp（blueprint）
与修补Bug相比，在增加Feature时穿上的那件“衣服”就是bp。
简单来说，bp主要阐述了有关新Feature的一些想法与设计，以及该bp的milestone，可以用于跟踪相关开发人员的开发进程。对于一些复杂的Feature，还会准备相关的Wiki页面。
与Bug类似，针对所有已经创建的bp，也可以去各个项目专属的页面查看相关的bp。Ceilometer的bp列表如图2-17所示。
图2-17 Ceilometer的bp列表
在如图2-17所示的页面中，列出了目前Ceilometer项目中已创建的所有bp，我们可以单击页面右上角的“Register a blueprint”按钮来创建一个新的bp，也可以打开bp列表中的任何一个bp进行查看。
创建bp的过程同样并不复杂，主要就是填写一个合适的标题并对Feature进行表述，困难的是bp在创建之后能够被接受。
项目的Core团队会针对所有创建的bp进行讨论，决定是否接受该bp，以及它的优先级。在bp被接受后，在开发过程中我们还需要适时更新开发的状态。一个具体bp的详细描述页面如图2-18所示。
图2-18 一个具体bp的详细描述页面
2.spec
在spec出现之前，我们在增加新Feature时，只需要给它穿一件很简洁的“衣服”，并创建一个bp，等待被讨论、接受即可。我们需要花费大量精力的地方在于如何让该Feature相关的patch被merge到项目中。
但是，在spec出现之后，需要穿的“衣服”就复杂了很多。各个项目逐渐又多了一个伴生项目<project>-specs，如Ceilometer对应的ceilometer-specs，我们需要在里面创建一个spec，然后像提交代码一样提交给Gerrit，以供项目的Core成员及其他开发者Review，在经过若干次的Update和可能比较漫长的等待之后，这个spec可能会被接受。
也就是说，在spec出现之前，我们增加一个新的Feature，需要经历一个Gerrit评审的过程，而在spec出现之后，这个Gerrit评审的过程变为了两个。
存在即合理，这个多出来的“衣服”肯定是为了更好地规范项目的开发。每个spec项目都会包含一个模板文件，每个新创建的spec必须按照这个模板逐项填写，包括相应的bp链接、问题的描述、对RESTful API等可能的影响、实现的设计细节及参考资料等内容。在填写完相应内容后，我们就基本上对实现的各种细节了然于胸，只剩代码了。
而原本的bp不需要考虑这么复杂，我们可以看到很多被接受的bp也只是寥寥几句，描述了一下想法而已。
3.提交patch
除了上述要穿上的“衣服”bp和spec，增加Feature时提交patch的过程与修补Bug时提交patch的过程大体相同，即把完成的代码提交到Gerrit供人Review。
我们同样不能直接在Master分支上进行实现，而是要针对这个Feature创建一个专门的分支，标准的流程应该是：
其中，“xenapi-support”是我们创建bp时指定的标题。当我们使用git commit命令提交代码时，不要忘记在描述信息里加上“Implements：blueprint xenapi-support”。
通过git review命令将我们的patch成功提交到Gerrit之后，就可以在Gerrit上打开该bp相应的页面来查看当前Review的过程并与其他开发者针对我们的实现进行互动。
2.6.4 Review
除贡献文档、代码以外，Review其他开发者的patch是我们向OpenStack做贡献的另一种重要方式。
30天内Nova项目的贡献排名如图2-19所示，除提交的patch数目以外，很重要的一部分就是Review的数目。
图2-19 30天内Nova项目的贡献排名
Engineer列在人名后面加“*”表示Core Developer，有“+2”与“-2”的权限。如果你想加入Core团队，则在这里面的排名尽量靠前是必要条件。
而Review本身只是要求我们花费一定的时间去浏览并理解其他开发者的代码，有针对性地提出自己的问题并做出“+1”或“-1”的评价。
如图2-20所示，在代码上双击即可出现输入框，可在此输入我们的疑问。
图2-20 Review代码
2.6.5 调试
这个世界从来就不缺少文艺青年，所以即使在IT博客论坛抑或书店的IT专柜，我们也经常会看到“编码的艺术”、“调试的艺术”及“注释的艺术”等融合了文艺气息和人文情怀的字眼。而与另外两种强调个体创造的“艺术”相比，“调试的艺术”需要在与机器的不断交流中完成，因此一些具有浪漫主义情怀的IT文艺男青年会说“我喜爱调试代码胜过了写代码”。
但是本书写不出这样的人文情怀，也相信看到这些文字的读者都已经写过且调试过很多的代码，即使不使用Python，也调试过C代码，对调试目的及包括断点在内的一些基本概念也都了然于胸。所以这里只简单介绍一种最为常用的OpenStack代码调试，也就是调试Python代码的方法——PDB。
使用PDB调试OpenStack代码，只需要在我们希望设置断点的地方加上下面的两行代码即可：
然后重启相应的OpenStack的各个服务，代码就会停止在这两行代码所在的地方，然后我们可以使用与PDB类似的一些命令进行调试，比如，使用p命令打印一些信息，使用n命令进行单步调试等。