如何提交补丁¶
此页面是从 MDN 导入的，内容可能已过时 |
提交补丁、获取审查并将其提交到 Firefox 源代码树涉及多个步骤。本文介绍了如何操作。
注意
我们还为贡献者提供了 Firefox 贡献者快速参考。
提交过程由下图说明，每个步骤在下面详细介绍
准备¶
对代码的每次更改都由 bugzilla.mozilla.org 中的错误报告进行跟踪。没有错误，代码将不会被审查，没有审查，代码将不会被接受。为了避免重复，搜索有关更改的现有错误，并且只有在不存在的情况下，才提交新的错误。大多数关于代码更改的通信发生在相关的代码审查中，因此请确保错误描述了解决的确切问题。
请验证错误是否适用于正确的产品和组件。有关更多信息，请在新闻组或 chat.mozilla.org 上的 #developers 房间提问。
处理错误的人员应为 Bugzilla 中该错误的“分配者”。如果其他人当前是错误的分配者，请发送电子邮件给此人以协调更改。如果错误未分配，请在错误的评论中留言，说明您打算处理它，并建议具有错误编辑权限的人员将其分配给您。
一些团队在新的贡献者附加他们的第一个补丁之前等待分配错误。如果新贡献者无法提升到补丁创建级别，这将使其可供其他贡献者使用。通过表达对错误评论的兴趣，该团队的某个人应该指导您完成他们的流程。
模块所有权¶
所有代码都由 模块所有者 监督。此人将负责审查和接受更改。在编写代码之前，确定模块所有者，验证您建议的更改是否被认为是可以接受的。他们可能希望查看任何新的用户界面 (UI 审查)、功能 (API 审查) 或建议更改的测试用例。
如果模块所有权不清楚，请在新闻组或 Matrix 上提问。相关文件的修订日志也可能会有所帮助。例如，查看 browser/base/content/browser.js 的更改日志，方法是单击 Searchfox 顶部的“Hg Log”链接，或运行 hg log browser/base/content/browser.js。相应的签入消息将包含类似“r=昵称”的内容，标识活动的代码提交和潜在的代码审查员。
处理补丁¶
对 Firefox 源代码的更改以补丁的形式呈现。补丁是对版本控制的提交。Firefox 和相关代码存储在我们的 Mercurial 服务器 中。我们在指南 Mercurial 概述 中提供了关于使用 Mercurial 的大量文档。
每个补丁都应表示一个完整的更改，将不同的更改分成多个单独的补丁。如果您的更改导致一个大型的复杂补丁，请查询是否可以将其分解成 更小、更容易理解的补丁，表示完整的步骤，并将其应用在彼此之上。这使得审查您的更改变得更容易，从而加快审查速度，并提高对审查结果的信心。
还要确保您的提交消息格式正确。简单的提交消息应如下所示
Bug 123456 - Change this thing to work better by doing something. r=reviewers
消息文本应为修复错误所做的操作，而不是错误的描述。如果此更改合适的原因不明确，则 在提交消息中解释原因。如果这在一行中不合适，则留空一行，并添加更多行以提供更多详细信息和/或推理。
r=reviewers 部分指定 reviewers 应审查补丁并在将其集成到 Firefox 代码库之前提供反馈。有关选择审查员和完整的审查员语法，请参阅 获取审查。
您可以随时使用 hg commit --amend 或 hg histedit 编辑当前提交的消息。
还可以查看我们的 审查员清单，了解审查员将检查或要求的补丁内容的最佳实践列表。
测试¶
所有更改都必须经过测试。在大多数情况下，对代码的每次更改都需要 自动化测试。
虽然我们希望对所有代码进行自动化测试，但我们还有一个 linter 工具，它对我们的 JavaScript 运行静态分析，以实现最佳实践和避免常见错误。有关更多信息，请参阅 ESLint。
通过在本地运行自动化测试套件或使用 Mozilla try 服务器，确保您的更改未导致回归。模块所有者或 Matrix 上的开发人员 可能愿意为那些目前没有 try 服务器权限的人员提交作业。
提交补丁¶
注意
在提交之前，请确保您将补丁重新定位到最新版本之上，以防止任何合并冲突。
Mozilla 使用 Phabricator 进行代码审查。有关说明，请参阅 Mozilla Phabricator 用户指南。
不要犹豫发布部分补丁，演示潜在的方法并请求初步反馈。当问题伴随着一些代码时，其他人更容易发表评论和提供建议。
获取我的补丁的审查¶
请参阅专用页面 获取审查
处理审查意见¶
补丁第一次就完美的并不常见。审查员可能会使用“请求更改” 操作 并列出在补丁被接受之前必须解决的问题。请记住，请求修订并非旨在阻止参与，而是鼓励以最佳方式解决错误。仔细处理审查员建议的更改，附加新的补丁，并再次请求审查。
有时审查员会使用“接受修订”操作授予有条件的审查，但也会指示一些必要的更改，例如拼写或缩进修复。所有建议的更正都应进行，但无需重新审查。进行更改并提交新的补丁。如果对修订有任何疑问，则应请求另一次审查。
有时，在补丁被审查但尚未提交之前，其他人会进行冲突更改。如果合并简单且非侵入性，请发布补丁的更新版本。对于所有非平凡的更改，都需要另一次审查。
如果在任何时候审查过程停滞超过两周，请参阅前面的“获取关注”部分。
在许多开源项目中，开发人员会接受处于未完成状态的补丁，完成它们，并应用已完成的代码。在 Mozilla 的文化中，**审查员只会审查和评论补丁**。如果提交者拒绝进行修订，则补丁将保持闲置状态，直到有人选择接手。
推送更改¶
补丁在经过适当审查后可以被推送（也称为“着陆”）。
注意
请务必使用应用的补丁构建应用程序。这确保它按预期运行，通过自动化测试，和/或运行 try 服务器。在错误中，请也提及您已完成此步骤。
提交未经测试的补丁会浪费提交者的时间，并可能烧毁发布树。请通过完成所有必要的验证来节省每个人的时间和精力。
请审查员为您着陆补丁。有关更多详细信息，请参阅 在代码库中推送更改
Lando 用于自动着陆您的代码。
回归¶
您的代码可能会导致功能或性能回归。特别是对性能回归有严格的 策略。这意味着您的代码可能会被删除，让您修复并重新提交它。回归最终意味着您在签入前运行的测试不够全面。重新提交的补丁或修复回归的补丁应附带相应的测试。
在编写了一些补丁之后，请考虑 获取对 Mozilla 源代码的提交访问权限。