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/