目录

 


 

对开发者而言会更加关注下面两个 Mailing Lists

• General List: openstack@lists.openstack.org

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

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

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

除此之外还有

• Announcements: openstack-announce@lists.openstack.org

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

在订阅了邮件列表之后,你的邮箱会不定期的收到非常对象Openstack资讯邮件,对及时了解Openstack的动态非常有帮助:

Openstack贡献者须知 2 — 社区工作运作 & 代码贡献流程_生命周期_03

社区工作运作流程

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
  • 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 代码贡献流程

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

Step1. 签署ICLA

 

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

 ​

Step4. 下载 Project 代码

使用 ​​git clone​​ 将最新的代码 ​​nova/master​​ 从服务器上拉到local(以nova为例)

gitclone 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
Addssome 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。

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

git commit -a --amend
git review


Step11. 最后

在 Gerrit 的代码审核和 Jenkins 的 Check Queue 通过之后,项目会交由 Jenkin s持续集成到代码库中。