[ English | Indonesia | русский ]
OpenStack-Ansible 缺陷处理¶
缺陷报告¶
缺陷应在 OpenStack-Ansible Launchpad 项目上提交。
提交缺陷或处理缺陷时，请确保满足以下标准
描述清晰地说明或描述了原始问题或问题的根本原因。
描述清晰地说明了用户操作的预期结果。
包含有关如何识别该问题的历史信息。
包含任何相关的日志或用户配置，直接包含或通过 pastebin 链接。
如果该问题需要在 master 分支以外的其他分支中修复，请在 launchpad 问题中注明相关的分支。
提供的信息应完全自包含。不应需要访问外部网络服务/站点。
如果可能，提供重现问题的步骤。
状态¶
请在有人确认或缺陷团队进行分类之前，不要更改问题的 状态。 在等待确认或分类时，状态应保持为 New。
重要性¶
只有当它是一个阻碍/阻止问题时才应更改。 如果是，请设置为 High，并且仅在您发现可能导致整个基础设施瘫痪的缺陷时才使用 Critical。 一旦重要性发生更改，状态应由缺陷创建者以外的人更改为 Triaged。
分类过程在下面解释。
缺陷分类¶
什么是缺陷分类¶
“缺陷分类是一个筛选和优先排序跟踪器问题（包括缺陷以及改进和功能请求）的过程。” (来源: Moodle 缺陷分类)
报告的缺陷需要确认、优先排序，并确保它们不会变得陈旧。 如果您关心 OpenStack 的稳定性，但不想积极开发 OpenStack-Ansible 项目中使用的角色和 playbook，请考虑参与缺陷分类工作。
请参考 项目团队指南 缺陷参考_ 以获取有关缺陷状态/重要性以及缺陷生命周期的信息。
缺陷分类会议职责¶
如果缺陷描述不完整，或者报告缺少重现问题所需的信息，请要求报告者提供缺失的信息，并将缺陷状态设置为 Incomplete
如果缺陷报告包含足够的信息并且您可以重现它（或者看起来有效），则应将其状态设置为 Confirmed。
如果该缺陷具有安全隐患，请设置安全标志（在右上角的“This report is public”下方）
如果该缺陷影响由官方标签覆盖的特定领域，则应设置该标签。 例如，如果该缺陷可能很容易解决，请添加 low-hanging-fruit 标签。
缺陷分类会议可能是具有缺陷主管权限的人员同时按重要性优先排序缺陷（除了按状态对其进行分类）的好时机。
缺陷筛选职责¶
为了帮助分类缺陷，缺陷团队的一名成员可以执行“缺陷筛选职责”。
- Q:
缺陷筛选职责的目标是什么？
- A:
缺陷筛选职责减少了其他开发人员花费在进行适当的根本原因分析（以及后续修复）缺陷报告上的工作量。 为此，关闭明显无效的缺陷报告，确认明显有效的缺陷报告，并在情况不明确时提出问题。
- Q:
在将其设置为 Confirmed/Invalid 之前，我需要证明缺陷报告有效/无效吗？
- A:
不。 有时甚至不可能，因为您没有资源。 查看代码和测试通常使您可以做出明智的猜测。 在评论中引用您的来源有助于讨论。
- Q:
如果无法重现问题，关闭缺陷报告的最佳状态是什么？
- A:
明确地是 Invalid。 状态 Incomplete 是一个开放状态，意味着需要更多信息。
- Q:
如何处理长时间处于 Incomplete 状态的开放缺陷报告？
- A:
如果它处于此状态超过 30 天且未收到对开放问题的答复，请将其关闭并标记为 Won’t Fix。
- Q:
如何处理对其他项目中的其他缺陷或 TBD 功能的依赖关系？ 例如，我可以在 OpenStack-Ansible 中修复一个缺陷，但需要 Compute (nova) 中的一个功能实现后才能进行。
- A:
在 OpenStack-Ansible 缺陷报告中留下评论，解释此依赖关系，并留下对您所依赖的其他项目的蓝图或缺陷报告的链接。
- Q:
我是否需要检查具有分配人的 New 缺陷报告？
- A:
通常不需要。 此缺陷报告具有不一致的状态。 如果缺陷报告具有分配人，则应为 In Progress 并已设置重要性。
缺陷筛选职责每周检查清单¶
优先处理或重新优先处理 OpenStack-Ansible 已确认的缺陷。
将一年前的 愿望清单缺陷移动到 Opinion/Wishlist 以减少混乱。 您可以使用以下消息
此愿望清单缺陷已开放一年且没有任何活动。 我将其移动到“Opinion / Wishlist”。 这是一个易于获取的旧请求队列。 如果有人决定处理此问题，可以重新打开此缺陷（设置回“New”）。
如果超过一个月未修改，则将无法重现的缺陷移动到无效状态。
向 openstack-discuss 邮件列表发送 本周要分类的缺陷列表。 新标记为 Critical 或 High 的缺陷必须优先处理。
