Openstack贡献者须知 2 — 社区工做运做 & 代码贡献流程

目录

前文列表

Openstack贡献者须知 — OpenPGP/SSH/CLA贡献者协议 php

订阅邮件列表 Mailing Lists

订阅邮件列表以后,你能够在邮件中提出问题并得到帮助。若是你有问题要提出能够直接发送邮件到相关版块的管理员那里去,社区的管理员会很是专业的回答你的问题。python

订阅邮件列表点这里(使用Launchpad Account Login)git

对开发者而言会更加关注下面两个 Mailing Lists
• General List: openstack@lists.openstack.org github

这里写图片描述

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

这里写图片描述

除此以外还有
• Announcements: openstack-announce@lists.openstack.org 编程

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

在订阅了邮件列表以后,你的邮箱会不按期的收到很是对象Openstack资讯邮件,对及时了解Openstack的动态很是有帮助:
这里写图片描述服务器

社区工做运做流程

Launchpad 上 Openstack 项目工做的运做流程。
Step1. Bugs 的处理流程app

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

  • 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
  • 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/

相关文章
相关标签/搜索