Fuel/如何贡献

加入 Fuel 团队

第一步

阅读 开发者指南 并了解如何设置帐户和 git。

克隆仓库

• git clone git://github.com/stackforge/fuel-main.git
• git clone git://github.com/stackforge/fuel-web.git
• git clone git://github.com/stackforge/fuel-astute.git
• git clone git://github.com/stackforge/fuel-ostf.git
• git clone git://github.com/stackforge/fuel-library.git
• git clone git://github.com/stackforge/fuel-docs.git

您可以 在 gerrit 中搜索与 Fuel 相关的所有评审，或者使用 Fuel 仪表板 获取一个优先排序的开放评审列表（此 URL 使用 Gerrit 仪表板生成器 生成，您需要登录 Gerrit 才能使用它）。

请注意，OpenStack Infra 对您的 git 提交消息有严格的检查。最重要的规则是

• 保持您的提交标题简短（小于 80 个字符）。它不能以句点结尾。
• 提交消息的正文应与标题之间用一个空行分隔
• 如果补丁关闭了错误，那么它必须在正文中包含“Closes-Bug: #12345”，其中 12345 是您的 LP 错误编号
• 如果补丁与错误相关，但没有完全解决问题，那么您必须使用“Related-Bug: #12345”

请参阅 Git 提交消息 wiki 页面以获取更多详细信息。

如何以及在哪里获取帮助

订阅邮件列表

• OpenStack 开发者邮件列表。如果您正在修改 Fuel，或者对 Fuel 内部有技术问题，欢迎使用带有“[Fuel]”主题的邮件列表。
• OpenStack 用户邮件列表。Fuel 流量带有“[Fuel]”主题。欢迎提问与 Fuel 使用相关的问题，包括错误等。
• OpenStack 公告邮件列表。关于 OpenStack 项目的公告，例如产品发布信息、安全建议、重要讨论。这是一个低流量的只读列表。
• 还有更多的邮件列表，请访问 邮件列表 以查看其他 OpenStack 相关列表。

freenode.net 的 IRC

• 通用的 Fuel 频道称为 #fuel，并且已记录 此处。
• Fuel 开发频道称为 #fuel-dev，并且已记录 此处。
• Fuel 主要组件的开发频道：#fuel-library、#fuel-python、#fuel-ui、#fuel-qa、#fuel-infra。
• Gerrit 通知所有 Fuel 仓库：#fuel-tracker。

快速参考开发链接

• 开发环境 http://docs.mirantis.com/fuel-dev/develop/env.html
• 如何构建您的 Fuel ISO http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
• Nailgun 开发 http://docs.mirantis.com/fuel-dev/develop/nailgun.html
• Health Check (OSTF) 贡献者指南 http://docs.mirantis.com/fuel-dev/develop/ostf_contributors_guide.html
• 贡献 Fuel Library（puppet 模块） http://docs.mirantis.com/fuel-dev/develop/module_structure.html
• Devops 框架 - Fuel 环境的分布式测试 http://docs.mirantis.com/fuel-dev/devops.html

贡献

Fuel 是编程、Linux 和网络交叉的大型项目。它使用 Python、Ruby 和 JavaScript 编写。它还具有 bash 和 make 中的许多构建脚本。文档使用 Sphinx 编写。欢迎新贡献者。

Fuel 用于 puppet 清单的库

在 fuel-library 中使用 puppet 上游模块

如果您要添加新的上游模块的分支 - 请不要这样做。相反，请遵循上游模块的贡献规则，并将此模块作为 Fuel 的可插拔组件提供。这可以作为 可插拔架构 的一部分完成，并作为软件包分发。请注意，如果上游模块不符合您的要求，您应该首先适应上游模块的需求，或者在紧急情况下，提供自定义补丁集作为 Fuel 插件分发的一部分。

具有与 Apache 2.0 不兼容的许可证（GPL 等）的模块将不被接受。*请注意许可证信息。*

案例 A：添加新的上游模块

如果需要使用新的 puppet 模块，则应通过 Puppetfile 添加该模块，如 Fuel/Library and Upstream Modules 页面中所述。您应该遵循 新模块 工作流程

案例 B：通过 Puppetfile 使用现有的上游模块

如果需要使用新的 puppet 模块，则应通过 Puppetfile 添加该模块，如 Fuel/Library and Upstream Modules 页面中所述。您应该遵循 更新现有模块 或 自定义上游模块更改 工作流程。理想情况下，所有上游更改都应首先在上游完成，并且可以使用简单的 Puppetfile 更新将其拉入 fuel-library。

案例 C：使用现有的上游模块

如果需要对尚未移动到 librarian-puppet-simple 工作流程的现有上游模块进行更改，则应遵循的工作流程是

1. 创建一个包含来自您正在使用的任何点的未修改的上游模块副本且没有其他相关修改的评审请求。

• 此评审应在提交消息中包含上游仓库的提交哈希。
• 应评估该评审以确定其适用性，并拒绝（对于许可、代码质量、过时的版本请求）或接受而无需修改。
• 该评审不应包含调用此新模块的代码。

2. 然后，应提出任何必要的更改以使其与 Fuel 协同工作作为依赖更改。

贡献到现有的 fuel-library 模块

作为 Puppet 模块的开发者，我们倾向于与 Puppet OpenStack 社区合作。因此，我们将所有改进、修复和自定义贡献给上游模块，以改进 Fuel。这意味着每个贡献者都必须遵循 Puppet DSL 基本知识、puppet-openstack 开发文档 和 Puppet rspec 测试要求。

最常见和普遍的规则是，只有当错误修复和改进可以使社区中的每个人受益时，才应修改上游模块。并且应在 Fuel 项目之前向上游项目提出适当的补丁。

在其他情况下（例如应用一些非常具体的自定义逻辑或设置），贡献者应提交补丁到 openstack::* 类

Fuel 库包含自定义模块以及从上游来源分叉的模块。请注意，如果存在 Modulefile（或 metadata.json），则应使用它来识别给定的模块是分叉的上游模块还是不是。如果模块的目录中没有 Modulefile，则贡献者可以直接提交补丁到 Fuel 库中的该模块。否则，他或她应首先提交补丁到上游模块，并且一旦合并或从核心评审人员处收到 +2，则应将补丁回移植到 Fuel 库。请注意，提交到 Fuel 库的补丁应在提交消息中包含上游提交 SHA 或指向 github pull-request 的链接（如果模块不在 stackforge 上）或 gerrit 补丁的 Change-Id。

Fuel 开发环境

VirtualBox

开始使用 Fuel 的最快方法是在 VirtualBox 下设置环境。这是开始测试的好方法，例如使用 nightly 构建来尝试验证、确认或分类错误。可以在 https://software.mirantis.com/quick-start/ 找到快速启动脚本和说明。

Fuel ISO 构建和开发环境

设置一个环境来构建 Fuel ISO 将允许您轻松地针对特定的提交构建，以便进行更复杂的错误测试/确认/分类/修复工作，或者用新功能增强 Fuel。除了准备 ISO 构建的环境之外，准备其他 Fuel 组件（nailgun、astute 和文档构建）的环境的步骤也可以在那里找到。可以在 http://docs.mirantis.com/fuel-dev/develop/env.html 找到准备环境的说明。

Fuel DevOps 环境

将 Linux 机器设置为 Fuel DevOps 环境将允许您自动化构建/验证/测试过程，除了构建 ISO 和进行其他 Fuel 相关开发之外。使用 libvirt，devops 环境能够部署多个完整的 OpenStack 环境在虚拟机上。可以在 http://docs.mirantis.com/fuel-dev/devops.html 找到准备 devops 环境的说明。

文档

Fuel 中有两种类型的文档：开发者 和 用户。两者的源代码都可以在 fuel-docs 仓库 中找到。该仓库使用 reStructuredText 格式。文档被视为源代码，我们使用相同的 开发流程 来更新文档，就像我们更新 Fuel 代码一样。

编写文档

保持文档的更新是一项艰巨的任务，也是每个项目中的关键部分。Fuel 开发者使用 OpenStack DocImpact 流程来突出显示需要反映在文档中的代码更改。当一个补丁集应该被记录或需要文档更改时，评审者应该要求提交者在他们的提交消息中添加“DocImpact”标签，并确保提交消息提供足够的信息关于代码更改的影响。当一个带有 DocImpact 标签的提交被合并时，一个新的错误将被自动创建并分配给 Fuel 文档团队。技术作者然后与提交者合作，将提交反映在文档中。

由 DocImpact 提交生成的错误应分配给 fuel-docs 团队，直到技术作者接手。技术作者从原始提交作者那里收集信息，并将其添加到正确的文档区域。最初提供信息丰富的提交消息是提交作者的责任，以便回答技术作者的问题，并审查解决该 DocImpact 错误的文档提交。

更新和扩展当前文档

如果您发现文档存在问题，请随时提交错误并提供修复程序，通过相同的代码贡献策略和程序。

编写发布说明

新功能

对于里程碑页面上列出的每个蓝图（例如 https://launchpad.net/fuel/+milestone/5.1），找到以下问题的答案

• 更改对用户有什么可见影响？
• 这之前是否记录为已知问题？

如果这是一个用户可见的改进，请添加一个新功能条目来描述它。解释该功能何时重要，如何启用它，以及当前的期望和限制。

如果它之前是一个已知问题，请添加一个已解决问题条目。

已知问题和已解决问题

扫描发布里程碑页面（例如 fuel 6.0）。审查所有针对当前里程碑的目标 bug，这些 bug 满足以下条件之一

• "release-notes" 标签
• 关键优先级
• 高优先级和“customer-found”标签。

在里程碑页面上按编号从高到低对 bug 表进行排序，以便您可以查看您已经审查过的 bug。如果当前里程碑的 bug 状态为 Fix Committed 或 Fix Released，请将其视为已解决问题列表。寻找以下问题的答案

• 这个问题是否存在于之前的 GA 版本中？（如果是，它将至少针对一个之前的发布系列，并将目标里程碑设置为该系列的维护版本。）
• 如何确认您的环境受到影响？（识别受 bug 影响的特定配置，包括错误消息或其他区分此 bug 的症状。）
• 如果受到影响，如何恢复？
• 问题的根本原因是什么，为了解决这个问题需要更改什么？

如果当前里程碑的 bug 状态为 Won't Fix 并且满足上述条件，请将其视为已知问题列表。需要回答的问题是

• 如何确认您的环境受到影响？
• 是否有解决方法？（如何防止此问题影响您？）
• 恢复流程是什么？

审查发布说明

发布说明的每个部分都有一个技术作者负责。作者识别需要在其部分中反映的功能和 bug。对于每个功能和 bug，作者会找到负责的软件工程师：功能负责人或最近 bugfix 的提交者。

如果无法从 bug 描述、blueprint 描述和规范以及相关提交的提交消息中获得足够的信息（如上述问题列表所示），则作者会私下联系工程师，请求更多信息。当功能或 bug 的描述在 gerrit 审查中发布时，作者会将工程师订阅到该审查中，并再次私下发送带有指向 Gerrit 中文档审查的链接和有关如何识别特定文档文件和行（例如 LP bug 号码、特定的 RST 文件、章节标题或标签等）的说明的请求。

Fuel 工程师必须优先处理这些信息和审查请求，以便在正常的开发过程中在一周内做出响应，并在硬代码冻结和 GA 发布期间的一天内做出响应。当未及时收到信息请求或审查请求的响应时，将使用标准升级流程。技术作者负责跟踪其发布说明部分的信息和审查请求以及升级的状态。

错误

验证 bug

这很容易上手，但这里的帮助实际上非常有价值。特别是对于仅与某些类型的硬件相关的 bugfix。当 bugfix 合并时，bug 会自动移动到“Fix Committed”状态。在 Fuel 中，只有在其他人验证后，我们才会为 bug 设置“Fix Released”状态。您可以简单地查看 所有 fix committed bugs 并开始验证它们。您需要加入 fuel-bugs LP 组才能更改 bug 状态。但是，您可以在 bug 报告中留下评论，这足以让 bug 管理员更改 bug 状态。如果您要求，您可以被添加到 fuel-bugs 团队中以自行管理 bug。

测试和报告 bug

您可以始终按照 http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso 中的说明从 master 构建开发人员 ISO。测试不同的部署模式，并提交 bug。请随时在 IRC 中分享您的发现，以获取您想了解的任何详细信息。您可以按照您想要的方式提交 bug，但是，如果 bug 包含所有详细信息，以便于重现并节省开发人员的时间，那就太好了。您可以遵循以下简单的指导，它略微扩展了官方 OpenStack Bugs 页面。

您为 Fuel 报告的 bug 可以是“Public”或“Private”。Private bug 仅对 Dev、QA 和 Support 团队可见。指导如下

• 通常您希望报告一个“Public” bug
• 但是，如果 bug 包含任何敏感信息或安全漏洞信息，请报告一个“Private” bug

在创建新 bug 之前，始终检查项目中是否已经存在类似 bug，并更新现有 bug 而不是创建稍后将被丢弃为重复项的内容。但是，重要的是要确保两个 bug 确实相关，处理重复项比理清混合到一个 bug 中的几个不相关的调查线索更容易。不要重新打开带有通用标题的 bug，例如“Horizon 崩溃”或“HA 无法工作”，这些标题可以涵盖整个根本原因范围。也不要创建带有此类标题的新 bug：尽可能具体地说明问题的性质。

以下是如何提交 bug

• 转到 https://launchpad.net/fuel
• 在右侧选择“Report a bug”
• 填写“Summary”字段以获取 bug。这将是标题。请描述性地简短扼要。
  • 不好 - "Sahara doesn’t install"
  • 好 - "Sahara fails to install in HA mode when “Neutron with VLANs” network is selected"
• 输入“Further information”。这是 bug 描述。它应包含以下部分
  • 重现步骤
    • 不好：在 HA 配置中运行部署
    • 好
      1. 创建一个新集群
      2. 选择 HA 模式，“Neutron with VLANs”用于网络，并选择安装 Sahara
      3. 将其余设置保留为默认值。运行集群安装
  • 预期结果
    • 好：Sahara 已部署，正在运行。
  • 实际结果
    • 不好：Sahara 安装失败。
    • 好：Sahara 安装失败，出现错误消息“xxx”。请参阅附件中的屏幕截图，其中显示“Logs”选项卡上的错误。
  • 解决方法
    • 不好：不要使用“Neutron with VLANs”
    • 好：将网络模式切换到“Neutron with GRE”以完成部署。
  • 影响
    • 不好：需要修复。
    • 好：无法完成部署，因为客户要求我们实施 Sahara 和“Neutron with VLANs”的用例。将配置更改为“Neutron with GRE”不是一个可接受的选项，因此必须尽快解决此问题。
  • 环境描述。提供足够的相关信息
    • 输出 http://fuel-master-node:8000/api/version/
    • shotgun2 report 命令的输出
    • 操作系统
    • 参考架构（HA / 非 HA）
    • 网络模型（Nova-network、Neutron+VLAN、Neutron+GRE 等）
    • 安装的相关项目（Sahara、Murano、Ceilometer）
• 在“This bug contains information that is”字段下选择 bug 的可见性。要么将其保留为“Public”（默认值），要么根据上述指导将其设置为“Private”。
• 在“Extra Options”部分添加附件
  • 日志
  • 诊断快照
  • 截图
• 在输入所有内容后，选择“Submit bug report”按钮

确认和分类 bug

Fuel 项目使用与其它 OpenStack 项目相同的 bug 管理实践。请遵循 Bugs 和 BugTriage 页面。

在 Fuel 部署过程中对 bug 进行分类

在对 Fuel 部署过程中的 bug 进行分类（与 Fuel 部署的 OpenStack 组件中的 bug 不同）时，请使用以下附加标准来确定 bug 的重要性

• Critical = 无法部署任何内容且没有简单的解决方法；数据丢失；或安全漏洞
• High = 某些硬件、配置或组件无法使用且没有解决方法；或者一切都已损坏，但有一个解决方法
• Medium = 某些硬件、配置或组件工作不正确；或者完全无法使用，但有一个解决方法
• Low = 次要功能已损坏，可以通过简单的解决方法修复；或者是一个外观缺陷
• Wishlist = 不是 bug，要么关闭为 Won't Fix，要么与 blueprint 关联（如果不存在涵盖 bug 中请求的功能的现有 blueprint，则创建新的 blueprint）

Fuel 还对两个 bug 状态有不同的含义

• Confirmed = 有人（不是提交者）查看了 bug 并确保其已正确分类。此人必须确保里程碑、重要性和分配者设置正确。但是，bug 可能尚未重现或确认是真实的。
• Fix Released = 有人（不是分配者）验证了修复后问题不再重现。此状态留给 QA 以在修复 bug 后将其标记为已验证。

用户体验 (UX) 问题附加指南

在某些情况下，bug 可能会对 UX 产生重大影响，在这种情况下，我们可以使用其他标准来设置 bug 优先级

• Critical = 需要大量精力才能解决，包括未记录/未充分记录的命令和对配置文件进行编辑
• High = 需要修改配置文件，用户不应使用的接口（例如，当它_应该_在 CLI / UI 中工作时使用 API（不包括仅应通过 API 可用的接口），或者需要自定义节点 yaml（同样，除非它应该仅通过 API 可用）
• Medium: CLI 中的简单命令
• Low 和 Wishlist = 如上

基础设施 bug 附加指南

• Critical = 至少一个团队被阻止或关键功能的交付被阻止，没有解决方法
• High = 关键问题有解决方法，或没有解决方法的其他基础设施回归，或关键严重程度功能的交付被阻止
• Medium = 有解决方法的基础设施回归，或需要交付中等严重程度的功能
• Low = 基础设施可靠性、可重现性或覆盖率改进
• Wishlist = 不符合更高优先级 UX 问题定义的化妆品基础设施改进

文档 bug 附加指南

• Critical = 遵循文档中的说明可能导致停机或数据丢失
• High = 文档包含不正确的信息，或指令无法产生广告效果
• Medium = 文档中缺少重要信息（例如，新功能描述）
• Low = 附加信息可以改善读者对功能的理解
• Wishlist = 格式和语法问题

Bug 分类例程

在对 bug 进行分类时，请使用以下例程

1. 审查所有 New bug。
2. 将每个 New bug 分配给正在开发中的发布系列（根据 Fuel 项目时间表 重点开发），并为该发布系列设置相应的 bug 状态和里程碑。
3. 考虑更改 bug 标题以使其更具体，用根原因的描述（如果已识别）或该 bug 独有的症状替换通用语句，例如“部署超时”。
4. 考虑 bug 的可见性状态。如果它包含敏感信息，请将其设置为 Private。如果它描述了安全漏洞，请将其设置为 Private Security。
5. 如果 bug 不包含如 Fuel/How_to_contribute#Test_and_report_bugs 中所述的足够信息，请请求缺失的信息，并将 bug 状态设置为 Incomplete。添加使用以下模板的评论：我们没有收到正确排除故障所需的详细信息，因此我们将此 bug 设置为 Incomplete 状态。请提供请求的信息，我们将进一步调查此问题。如果您认为它被错误地设置为 Incomplete，请在 bug 中评论。
6. 根据 Fuel/Bug_tags#Area_tags 列表添加区域标签。
7. 从 Fuel bug tags taxonomy 添加其他适用的标签。
8. 如果有关如何重现 bug 的信息足够，并且里程碑、重要性和分配者设置正确，则将状态设置为 Confirmed。
9. 如果有关如何开始实施修复的信息足够，则将状态设置为 Triaged。
10. 如果 bug 的根本原因已确定，请将其包含在 bug 描述中。
11. 审查所有 Incomplete bug
12. 如果 Incomplete bug 有新的更新，请按照上述 New bug 的步骤操作。
13. 如果 Incomplete bug 在 4 周内没有更新，请将其关闭为 Invalid。添加使用以下模板的评论：此 bug 不完整超过 4 周。我们无法进一步调查它，因此我们将状态设置为 Invalid。如果您认为不正确，请随时提供请求的信息并重新打开 bug，我们将进一步查看它。
14. 在发布进行 Code Freeze 时，审查所有针对该发布里程碑的 bug，确保分配者（或 bug 报告者，如果 bug 未分配给任何人）每天更新它。
15. 如果您知道该 bug 与某些 blueprint 相关，请将此 bug 链接到这些 blueprint。为此，请转到相应的 blueprint 页面并点击“Link a bug report”链接。

请记住，bug 的每个状态更改都必须附带一个解释为什么进行更改的评论。

有用的 LaunchPad 搜索和工具

• 新错误
• Incomplete bug
• 未分配的 bug
• fuel-library 中的 bug，按里程碑排序
• Firefox 的 Launchpad Helper
• Chrome 的 Launchpad Helper

修复 bug

为 Fuel 贡献代码的最简单方法是从 bug 修复开始。首先，查看 带有“low-hanging-fruit”标签的 bug。您也可以选择任何其他 bug。为了更轻松地管理 bug，Fuel 使用多个功能组，您会看到 bug 分配给 fuel-python、fuel-library、fuel-qa 和其他团队。随意选择其中任何一个。它分配给组，以便组可以收到有关 bug 的电子邮件通知。除非它重新分配给特定工程师来处理该 bug，否则这意味着该 bug 尚未被任何人采用，因此您可以随意采用它。分配给某个人的 bug 并不一定意味着有人正在处理它们（但理想情况下应该如此）。即使它处于“正在进行中”状态，也请随意联系该人并询问他是否真的在处理该 bug，如果确实如此，请随意分配给自己。

带有 swarm-blocker 标签的 bug 的特殊流程

带有“swarm-blocker”标签的 bug 会阻止我们的夜间测试，应尽快修复。其他开发人员也可能被这类 bug 阻止。我们对这些 bug 有两个额外的要求，以改善沟通、规划、分析和减少它们的发生。

修复 bug 的开发人员应提供带有“ETA: date-of-merge”文本的评论，其中包含当前发布版本的初步修复交付日期。此信息应在分配 bug 的日期提供，并在需要时使用新的评论进行更新。

修复 bug 的开发人员还应提供带有“RCA: root-cause-analysis”文本的评论，其中描述了 bug 出现的原因。理想情况下，它应包含指向回归审查的链接。其他常见情况是“新的测试用例”和“测试用例中的 bug”。此信息应在可用时提供。之后，开发人员应添加“rca-provided”标签。

将 bugfix 回溯到稳定的发布系列

当您创建一个新的高或关键优先级 bug 或升级现有 bug 时，请始终检查它是否存在于受支持的稳定发布系列中（至少是最新的稳定发布系列）。如果存在，请将其定位到所有受影响的系列（即使您不期望最终能够回溯修复）。如果它不存在于稳定版本中，请在 bug 上记录下来，以便其他人不必重新检查。

当你提出一个 bug 的修复方案时，请始终从在主分支（master branch）中修复它开始。如果修复方案仅适用于稳定分支，并且与主分支无关，请在提交消息中说明。对于针对稳定发布系列的 bug，在修复方案合并到主分支后（之后），将修复提交 cherry-pick 到每个目标系列的稳定/x.x 分支（过早创建 backport 可能会导致主分支和稳定/x.x 版本之间相同提交的不一致）。使用相同的 Change-Id 和主题（git review -t bug/<id>）以便更容易追踪该 bug 的所有 backport。如果提交可以无冲突地应用于稳定分支，也可以在 Gerrit 中使用“Cherry Pick To”按钮。请注意，通常来说，作者 如何管理补丁的 Change-Id 由作者决定，但我们坚持在所有相关的 backport 中保持 Change-Id 相同。

当你批准主分支的 bug 修复提交时，请使用目前关于该 bug 和审查请求中的信息来审查并可能更新 bug 的 backporting 状态。它的优先级是否足够高，需要进行 backport？它是否针对所有受影响的发布系列？是否已经存在 backport 提交？如果是，它们是否与合并到主分支的提交保持最新？

• 对于应该存在 backport 但实际不存在的每个系列，请自行创建一个 backport 审查请求。
• 对于所有其他受影响的系列，将 bug 状态更改为 Won't Fix，并在 bug 注释中说明原因。
• 除非提交消息明确说明为什么不适用于主分支，否则不要将提交合并到稳定分支，直到它被合并到主分支。

当你在稳定发布中发现一个 bug 时，不要简单地将其定位到该维护发布系列中的下一个发布版本。相反，将其定位到 Launchpad 上的 Fuel 主页上指定为“当前重点”的发布版本。如果这是一个高优先级或关键优先级 bug，则此外还将它定位到最初发现该 bug 的发布系列，以及（如果适用）所有介于两者之间的发布系列。

如果一个 bug 存在于维护发布中，但不存在于当前发布系列中，它应该在当前发布系列中具有以下状态之一

• 不完整，如果根本原因分析尚未完成
• 已修复，如果根本原因分析表明该 bug 已通过在 bug 发现的维护发布之后合并的更改修复
• 无效，如果根本原因分析表明该 bug 是由特定于此维护发布系列的更改引入的

增强功能

提出增强功能

Fuel 的增强功能使用蓝图机制提出。该过程与 bug 非常相似

• 选择“注册蓝图”。通常，你会在 launchpad 页面的右侧找到此链接。
  • 输入蓝图的名称。如果可能，请将 fuel 的子组件名称作为名称的第一个词（或者对于更广泛的蓝图，只需使用 fuel），然后使用连字符分隔的简短描述符。例如，ui-declarative-wizard 或 fuel-stop-deployment。
  • 输入蓝图的标题。标题应尽可能清楚地描述该功能，最多 70 个字符。此标题将显示在每个功能列表或报告中。
• 输入蓝图的摘要。
  • 用用户故事总结蓝图的想法。如果你在公共文档中有一个现有的用户故事，请包含该链接。
  • 如果尚未创建公共文档并且用户故事很长，可以使用 https://etherpad.openstack.org/ 来记录完整的用户故事。你可以将用于蓝图的名称作为 Pad 名称。
• 通过选择你计划完成蓝图的里程碑来提出你的蓝图。
• 你不需要输入任何其他字段，现在只需选择注册蓝图即可。

如果你只是输入一个没有设计的新想法，你可以将规范 URL 字段留空。如果你有设计，以下是如何发布和批准它

• 将设计规范上传到 fuel-specs 中的“specs/<release>”文件夹
  • 例如，access-control-master-node
  • 它应基于 模板，有关更多详细信息，请参阅模板中的说明
  • 通过 Gerrit 提交您的补丁以进行审查，以通常的方式：开发工作流程
  • 在每个版本的结束时，未完成的规范将被删除
  • 如果蓝图延期，您需要重新提交以供下一个版本使用

• 为了使你的规范获得批准，通常需要获得以下人员的 +1
  • 所有强制性设计审查员（通常是熟悉所提议增强功能领域的专家）
  • 如果有主题专家（例如，你的增强功能以某种方式影响 Fuel Web UI，那么你需要从 Fuel Web UI 团队获得 +1）
  • QA
  • 对于跨组件的增强功能，还需要获得受影响组件核心的 +1。

• 一旦你的设计规范获得批准并合并到 fuel-specs git 仓库中
  • 将你的蓝图的规范 URL 更新为指向 fuel-specs git 中的设计规范
  • 请注意，这应该链接到 git（如上面的模板链接），而不是 gerrit 更改

完成后，向邮件列表发送一封关于新蓝图的电子邮件，以吸引 Fuel 开发人员的注意，他们可能会提供早期反馈并要求更多信息。

请阅读 OpenStack Blueprints 页面，以获取蓝图及其生命周期的详细定义。

实现新功能

要实现新功能，你需要解决以下问题

1. 提交一个蓝图，其中包含所有必需的功能详细信息，如 Propose enhancements 部分和 Blueprints 页面中所述
2. Fuel 的 PTL 或核心开发人员应在提供所有必要信息后批准蓝图。
3. 请不要进行任何积极的贡献，除非对设计达成一致。要获得批准，你可以在邮件列表中讨论该功能。
4. 每个新功能不得破坏其他功能，并且无论与我们之前拥有的功能一起工作得如何，或者与不适用于新功能的那些功能一起禁用。
   • 所有发行版（当前 CentOS 和 Ubuntu）
   • 网络（nova-network、Neutron）
   • 节点上与其他角色的组合。例如，MongoDB 角色不应与 Ceph 放在一起。
   • 磁盘分区（它将使用现有分区还是需要创建新分区？）
   • 网络验证
5. 功能的其他要求
   • 对于 Fuel Library 的贡献，服务的日志记录应通过 rsyslog 进行
   • 实现应该是可扩展的，否则限制应在设计文档中明确说明。降低现有功能的扩展性和性能是不可接受的。
6. 开始实现并频繁地提出小块的代码更改。这是成功合并的唯一途径——审查 1000 多行代码的更改集是不现实的。
7. 每个功能都应该有一套测试
   • CasperJS 和 Selenium 测试用于 Fuel Web UI
   • Nailgun 使用 Python Unit Test 框架 进行单元和集成测试
   • Astute 使用 RSpec 进行单元和集成测试
   • 考虑扩展 OSTF 测试 以实现该功能
   • 系统测试，它使用 Devops 框架，在 ISO 上运行，即当所有组件集成时。系统测试持续长达 6-8 小时，并且每晚运行一次。由于这些测试是在集成环境中运行的，因此其结果代表着更高的兴趣。每个在多个 Fuel 组件中都有部分的大型功能都必须由系统测试覆盖。
   • 如果功能需要特殊硬件或特殊部署设置，则应通过添加此类硬件和对 devops 框架的必要更改来扩展现有的 CI。应在邮件列表中与 Fuel 社区讨论，以便达成共同的决定。
8. 文档。新功能必须在 用户和开发文档 中得到充分记录。
9. 请在功能冻结日期之前提出功能的更改。否则，在代码冻结之前甚至不会审查更改，并且我们不会在创建所提议分支的里程碑之前将更改合并到主分支。这将允许 Fuel 团队专注于当前版本的稳定化，并将所有力量投入到修复 bug 中。规则与核心 OpenStack 项目类似，请参阅 FeatureFreeze 和 ReleaseCycle。

带有“feature”标签的 bug

我们有一个专门的交付团队致力于小的增强功能，以弥补 Fuel 功能中的差距

它处理带有“feature”标签的 bug 和估计持续时间小于 5 个工日的微型故事

你可以在 Enhancements Team Trello Board 上跟踪这些活动

测试

Nailgun 的单元和集成测试

Nailgun 使用 Python Unit Test 框架 进行单元和集成测试。帮助编写测试非常值得赞赏——我们始终希望获得更好的覆盖率！请查看 如何设置 Nailgun 单元测试开发环境，并遵循 How to Test Your Code 指南。

代码审查规则

向 Fuel 贡献代码更改时，请使用 开发工作流程 并遵循 Fuel 特定规则和建议。