跳转到: 导航, 搜索

Solum/贡献

开始之前

为了熟悉 Solum,请使用我们入门指南中的信息来试用它。 当你准备好开始贡献时,你需要执行一个OpenStack CLA。 在你可以向我们的Solum Repo提交评审之前,这是必需的。 有关如何准备贡献的信息,请参阅如何贡献 wiki 页面。

了解 Gerrit

请务必阅读开发者指南,了解如何提交你的提交以供评审,以便将其合并到 Solum 代码库中。

设置你的 git review 设置

 git config --global user.name "Firstname Lastname"
 git config --global user.email "your_email@youremail.com"
 git config --global gitreview.username "your_launchpad_username"

要检查你的 git 配置

 git config --list

安装 git-review

在 Ubuntu、MacOSx 或大多数其他类 Unix 系统上,它就像这样简单

 pip install git-review

开发者指南中详细介绍了其他安装选项。 现在你可以签出 Solum 代码并开始使用它了

你的第一次提交

设置你的本地分支

 git clone git://git.openstack.org/openstack/solum
 cd solum
 git checkout -b [branch name]
 git review -s

编写一些很棒的代码

此时,你可以编写代码并将其推送到 Gerrit 以供评审。

 git add <list of files you added/changed>
 git commit -a
 git review -v --draft

当你对你的代码感到满意并希望对其进行评审时,你需要将其从草稿状态转换为正式提交。 在 https://review.openstack.org/ 上“登录”,并在自行验证评审后,点击页面上的“发布”按钮。

如果你知道你已经准备好让其他人评审你的代码,你可以跳过草稿步骤,直接执行

git review -v

如果你想根据反馈在评审系统中修改你的补丁集,请进行更改,然后使用

git commit -a --amend
git review -v

在评审获得批准后,你的代码将被自动合并。

审查

OpenStack CI 系统使用核心评审者的概念。 这些是那些持续评审项目代码,并在相当长的时间内帮助提高代码质量和一致性的人员。 项目贡献者会认为这位评审者对团队有积极影响,并且他们维护了 OpenStack 开发社区的价值观和传统。

政策

现有的核心评审者可以在 ML 线程中提名新的核心评审者。 当前评审者之间的同意将导致 PTL 宣布新的核心评审者。 缺乏一致同意应仔细考虑,并且由 PTL 根据活跃团队成员的意见做出最终决定。 被同级核心评审者认为未达到核心评审者的期望贡献水平的核心评审者可能会被提名恢复到普通评审者状态。

当前的 Gerrit 策略是

label-Code-Review = -2..+2 group solum-core
label-Approved = +0..+1 group solum-core

补丁需要核心评审者标记评审为“批准”才能合并。

审查指南

合并的代码批准

  • 为了获得批准,需要两个核心评审者提供 +2

继续他人的贡献

  • 如果一个贡献者提交的补丁被另一个贡献者接手并完成,则应使用特殊处理来解决问题。

给评审者的建议

  • -1 投票是一个改进我们代码的机会,然后再将其合并。 请尽最大努力提出有帮助、可操作的 -1 投票。
  • 避免盲目地 +1 代码的诱惑,而没有以足够的细节进行评审,以形成意见。
  • 当你对补丁投票 -1 时,这意味着你希望提交者根据你的反馈进行修改,然后核心评审者才能考虑将此代码合并。
  • 如果你提出问题,你应该投票 0,除非你预计该问题的答案可能会导致你对补丁进行反对投票,而无需进一步修改。
  • 如果你使用 -1 投票提问,并且贡献者回答了问题,请回复确认该问题。 更改你的投票或跟进,提供更多理由说明为什么应该保持 -1 评论。
  • -2 投票是单个核心评审者的否决权。 它是粘性的。 这意味着即使你修改了补丁,该投票仍然会保留。 为了允许你的补丁合并,相同的评审者必须首先清除 -2 投票。 此投票用于当你贡献的内容与当前项目愿景不一致,或者以无法接受的方式实现时。 例如,核心评审者想要单独重新评估的安全问题。 它也可以用作一种停止对补丁进行进一步门控测试的方式,如果包含可能破坏门控测试的内容。 它甚至在 2*+2,+A 批准合并后,但在补丁达到 MERGED 状态之前仍然有效。
  • 为了避免 -2 投票,请在编写代码之前与开发团队讨论你的计划,并在工作时发布 WIP(workflow-1)补丁,并征求意见,然后再提交以供合并评审。

测试

请参阅我们的 Solum/Testing wiki。