作者：九州雲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 [email protected]此處填寫要與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。