来自 GitHub 的回归问题¶
发布管理和每周回归问题评审必须了解所有报告的回归问题的状态，以确保我们不会在 Firefox 版本中发布已知的回归问题。
如果一个团队使用 GitHub 来管理他们 Firefox 项目的一部分，那么这些团队可能看不到回归问题。
我们需要一个商定的标准来跟踪这些问题。
策略¶
所有 Firefox 组件，即使其缺陷在 Bugzilla 之外跟踪，也必须在 Bugzilla 中有一个组件。
如果在任何发布分支（Nightly、Beta、Release 或 ESR）中发现回归问题，并且该缺陷位于使用外部存储库的 Firefox 组件中，则必须在 Bugzilla 中跟踪该回归问题（无论该组件是否使用外部问题跟踪器）。
除非发布管理批准，否则任何具有未解决的回归问题的 GitHub 托管代码都不得合并到 mozilla-central。即使该回归问题不是之前已合并到 mozilla-central 的代码。
所有在 GitHub 中管理并使用 GitHub 管理问题的 Firefox 代码 必须使用共享标签。
最佳实践¶
您必须在 Bugzilla 中提交回归问题缺陷¶
如果包含回归问题的代码已合并到 mozilla-central，则您必须提交回归问题缺陷。
示例¶
在使用 Firefox 版本（Nightly、Beta、Release、ESR）时，您遇到了一个缺陷。使用 MozRegression 或其他工具进行研究后，您发现该缺陷是在从代码和问题在 GitHub 中管理的组件导入的更改集中引入的。
采取的措施¶
在 Bugzilla 中适当的组件中打开一个新的缺陷，并添加 REGRESSION 关键字
为出现缺陷的版本设置受影响状态
在相应的 GitHub 项目中打开一个问题，在标题中使用前缀“Bug”加上 Bugzilla 缺陷编号（例如，“Bug 99999: foo 中的回归问题”）
在新问题中添加 REGRESSION 标签
将 GitHub 问题的链接添加到 Bugzilla 缺陷的“参见”字段中
后果¶
在回归问题修复或从 GitHub 存储库中撤销之前，该项目无法将代码合并到 mozilla-central
示例¶
您将 GitHub 中管理的组件的开发分支导入到您的 master 副本中。您发现了一个缺陷并将其隔离到导入的分支中。该代码在他们自己的 GitHub 项目中管理，但缺陷在 Bugzilla 中管理。
采取的措施¶
在 Bugzilla 中适当的组件中打开一个新的缺陷，并添加 REGRESSION 关键字
为出现缺陷的版本设置受影响状态
后果¶
在回归问题修复或从 GitHub 存储库中撤销之前，该项目无法将代码合并到 mozilla-central
不要在 Bugzilla 中提交回归问题缺陷¶
如果包含回归问题的代码尚未合并到 mozilla-central，则您无需提交缺陷。
示例¶
您将 GitHub 中管理的组件的开发分支导入到您的 master 副本中。您发现了一个缺陷并将其隔离到导入的分支中。该代码和问题在他们自己的 GitHub 项目中管理。
采取的措施¶
在导入代码的 GitHub 存储库中提交新问题。
将问题标记为 REGRESSION
后果¶
在问题解决或撤销之前，该问题会阻止 GitHub 项目与 mozilla-central 的合并。
注释¶
缺陷**必须**包含回归问题关键字。
缺陷**必须**设置受影响版本。
如果团队在外部缺陷跟踪器中工作，则 Bugzilla 缺陷**必须**使用“参见”字段引用外部跟踪器中缺陷的 URL。
缺陷**不得**设置为已解决，直到包含该缺陷更改集的外部存储库中的代码已合并到 mozilla-central。当更改集合并到 mozilla-central 后，Bugzilla 跟踪缺陷应设置为已解决并已修复，并且应更新版本状态标记以反映已合并或提升到其中的发布分支。
如果包含回归问题补丁的更改集因任何原因从 mozilla-central 回滚，则跟踪该回归问题的缺陷**必须**设置为重新打开，并相应更新版本状态标记。
如果包含缺陷补丁的更改集因任何原因被撤销，则必须重新打开缺陷，并更新 Bugzilla 跟踪缺陷上的状态标记。
负责包含回归问题的组件的团队**应该**努力为 mozilla-central 创建一个补丁，该补丁仅包含缺陷的修复，而不是包含其他多个缺陷或功能更改的整体补丁。
第三方库的合并 必须包含清单文件。