Openstack貢獻者須知 2 — 社區工做運做 & 代碼貢獻流程

目錄

• 目錄
• 前文列表
• 訂閱郵件列表 Mailing Lists
• 社區工做運做流程
• Openstack 代碼貢獻流程
• PEP8 Python編程風格
• 查閱相關資源

前文列表

Openstack貢獻者須知 — OpenPGP/SSH/CLA貢獻者協議

訂閱郵件列表 Mailing Lists

訂閱郵件列表以後，你能夠在郵件中提出問題並得到幫助。若是你有問題要提出能夠直接發送郵件到相關版塊的管理員那裏去，社區的管理員會很是專業的回答你的問題。

訂閱郵件列表：點這裏(使用Launchpad Account Login)

對開發者而言會更加關注下面兩個 Mailing Lists ：
• General List: openstack@lists.openstack.org

• Future Development: openstack-dev@lists.openstack.org

除此以外還有：
• Announcements: openstack-announce@lists.openstack.org

• OpenStack Operation: openstack-operations@lists.openstack.org

在訂閱了郵件列表以後，你的郵箱會不按期的收到很是對象Openstack資訊郵件，對及時瞭解Openstack的動態很是有幫助：

社區工做運做流程

Launchpad 上 Openstack 項目工做的運做流程。
Step1. Bugs 的處理流程

There are 4 key tasks with regards to bugs that anyone can do:

• Confirm new bugs: A 「New」 bug can be marked 「Confirmed」 once it has been reproduced and is thus confirmed as genuine.

• Solve inconsistencies: Make sure bugs are Confirmed, and if assigned that they are marked 「In Progress」

• Review incomplete bugs: See if information that caused them to be marked 「Incomplete」 has been provided, determine if more information is required and provide reminders to the bug reporter if they haven’t responded after 2-4 weeks

• Review stale In Progress bugs: Work with assignee of bugs to determine if the bug is still being worked on, if not, unassign them and mark them back to Confirmed or Triaged.

Step2. Blueprints 的處理流程
Many OpenStack projects teams have a -specs respository which is used to hold approved design specifications for additions and changes to the project team’s code repositories.

Step3. Spec + Blueprints 的生命週期
For projects using a -specs repository (like Nova, Neutron, Oslo, Ceilometer…), you should follow this process:

• Register your blueprint in Launchpad
• Upload a design specification in the 「specs/」 folder in $PROJECT-specs
  
  • e.g. http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/name-ofyour-blueprint-in-launchpad
  • it should be based on the specs/template.rst
  • get it reviewed by submitting your patch using Gerrit
  • at the end of each release, non-completed specs will be removed
  • you need to re-submit for the following release, should the blueprint slip
• Project drivers will approve blueprint by:
  
  • Setting priority
  • Setting a target milestone, based on the assignee proposal
• Assignee sets implementation status to 「Implemented」

Step4. Blueprints 獨立的生命週期
Projects not using a -specs repository (Horizon, Trove…), you should follow this process:

• Register your blueprint in Launchpad
  
  • Describe the feature summarily in the blueprint itself
  • Link to another document (using the specification link) if you have more
  • Set yourself as assignee
  • Set target milestone to indicate when you expect the work to land
• Project drivers will approve blueprint by:
  
  • Setting priority
• Assignee sets implementation status to 「Implemented」

Openstack 代碼貢獻流程

Step1. 簽署ICLA
點這裏，注意必定要把信息填全，特別是https://review.openstack.org/#/settings/contact頁面的信息。

Step2. 上傳本身的SSH Key
須要經過 SSH 向 Gerrit push 代碼

Step1 & Step2 看能夠參考Openstack貢獻者須知 — OpenPGP/SSH/CLA貢獻者協議

Step3. 配置Git Bash(Ubuntu 16)

• Install Git

sudo apt-get install git

• Let git know your email address

git config --global user.name "guiju fan"
git config --global user.email "fan_guiju@xxx.com" #注意跟Gerrit帳戶一致

• Check your Git Configuration

git config --list

• Check your git config file)

cat $HOME/.gitconfig

• Install git review)

apt-get install git-review

參考文檔：http://www.mediawiki.org/wiki/Gerrit/git-review

Step4. 下載 Project 代碼
使用 git clone 將最新的代碼 nova/master 從服務器上拉到local(以nova爲例)

git clone git://github.com/openstack/nova.git

Step5. 讓 Project 感知代碼審覈工具 Gerrit
須要先確保能使用你的 SSH key 登陸Gerrit，建議使用上述進行配置的 git 環境變量的用戶(EG. fan__guiju@xxx.com)來操做。不然，會提示輸入Gerrit用戶名.

cd nova
git review -s

成功後，會在 nova 目錄下生成一個 .gitreview 目錄

Step6. 確保下載的 Project 代碼是最新

git checkout master
git pull

Step7. 新建 Projecy 分支
1. 若是操做類型是 blueprint，那分支名應該是bp/BP-NAME，其中 BP-NAME 是在launchpad 上 的 bp名稱。
2. 若是操做類型是是修復 bug，那麼分支名是bug/BUG-NUMBER，其中 BUG-NUMBER 應該能夠在 Openstack Bugs 頁面上找到：

新建分支後再使用 git brance 指令肯定分支切換到了 BRANTCH-NAME

git brance
git checkout -b BRANTCH-NAME

Step8. 提交代碼

• 添加提交信息
  在單獨的一行中填寫 Summary(小於50個字符)，空隔一行，而後在第二段進行詳細的描述。若是是實現 blueprint 或修復了 bug，需註明：
  blueprint BP-NAME
  bug BUG-NUMBER

Adds some summary less than 50 characters   

...Long multiline description of the change...   

Implements: blueprint authentication   
Fixes: bug #123456 

• 經過進行代碼的單元測試(Unit tests)後提交代碼

git commit -a

• 申請Gerrit review 代碼

git review  #經過Gerrit審覈提交的代碼

Step9. Review code
申請 review 後，代碼審覈工程師就能夠進行代碼審覈。你的提交會出如今https://review.openstack.org 頁面上，能夠查看提交的狀態和信息。在Gerrit審覈代碼的過程當中，還會調用 Jenkins 進行自動 Check Queue。

若是在 Jenkins 中報出了 failure，能夠查看日誌來進行排錯。若是確認不是本身的 patch 致使，能夠在 comment 裏留 recheck no bug，從新讓 Jenkins 進行自動化 Test 。

Step10. 修改
若是代碼審覈沒有成功的話，Gerrit會返回並提示須要修改的代碼，在修改完後再次提交時必定要直接使用已存在的Change-Id。

git commit -a --amend
git review

Step11. 最後
在 Gerrit 的代碼審覈和 Jenkins 的 Check Queue 經過以後，項目會交由 Jenkin s持續集成到代碼庫中。

PEP8 Python編程風格

Read http://www.python.org/dev/peps/pep-0008/

查閱相關資源

OpenStack Documents:
• https://wiki.openstack.org/wiki/Document

Developer document:
• https://docs.openstack.org/developer/<projectname>:

Release Progress：
• http://status.openstack.org/release/

OpenStack Blogs：
• http://planet.openstack.org/
Sebastien Han(eNovance)：
• http://www.sebastien-han.fr/blog/