错误生命周期

目录

• 引言
• 新的、未确认的错误
• 确认错误
• 分析错误
• 提出修复方案
• 审查提议的修复方案
• 提交补丁
• 验证修复
• 关闭错误

引言

本文档描述了 WebKit 开源项目中错误的生命周期。在大多数方面，这与任何 Bugzilla 项目中错误的生命周期相同。Bugzilla 网站也包含关于 Bugzilla 错误生命周期的更多详细信息。

新的、未确认的错误

新创建的错误最初处于 UNCONFIRMED（未确认）状态。通常它在 New Bugs（新错误）组件中，但有些错误会在最初的错误报告步骤中被赋予初始组件。

确认错误

下一步是让拥有 Bugzilla canConfirm 权限的人审查未确认的错误，并决定它是否包含足够有用的信息以继续推进。此步骤中可能对错误进行的更改包括以下内容

• 如果错误被确定与早期报告的错误具有相同的原因，则解决方案更改为 DUPLICATE（重复）。
• 如果错误似乎在最新源代码中不存在，则解决方案更改为 WORKSFORME（在我这可行）。
• 如果错误未描述 WebKit 的问题，则解决方案更改为 INVALID（无效）。
• 在极少数情况下，如果错误看起来有效但有特定原因不应在 WebKit 中修复（通常是跨浏览器兼容性问题），则解决方案更改为 WONTFIX（不予修复）。
• 如果错误没有足够信息以继续推进，则添加评论/问题。
• 如果错误可以通过 OS X 上的最新源代码重现或包含足够信息以继续推进，则状态更改为 NEW（新建）。如果错误无法通过最新源代码重现，但似乎仅在平台字段中说明的平台上出现，则添加 PlatformOnly 关键字，并将状态设置为 NEW。除了更改状态，如果需要，组件也应设置为比 New Bugs 更具体的适当组件。

分析错误

每个错误最初都会分配给指定为组件所有者的人员。在阅读错误并确认其代表 WebKit 中的实际问题后，受分配人应将错误从 NEW 状态更改为 ASSIGNED（已分配）状态。如果他们对此不满意，应执行上述确认错误部分中提到的操作之一。对于状态为 REOPENED（重新打开）的错误，也遵循相同的程序（参见下文验证修复）。

受分配人代表预期将进行下一步错误调查或修复工作的人员。如果除受分配人之外的其他人正在调查或修复错误，则受分配人应更改为正在进行工作的人员。这有助于防止重复工作。添加解释受分配人为何更改的评论总是有帮助的。

提出修复方案

应将提议的补丁作为新附件添加。附件应勾选 patch 复选框，并将 review 标志设置为 ?。这表示补丁正在等待审查。如果补丁需要特定审查者的专业知识，提交者或另一位审查者应将请求的审查者的电子邮件地址填写到 Requestee 字段中。否则，此字段应留空。此时状态仍保持在 ASSIGNED；直到修复已提交到源代码树中，状态才会更改为 FIXED。

当审查标志的状态改变，或在附件的编辑表单中添加评论时，电子邮件会自动发送到 webkit-reviews 邮件列表。所有审查者都订阅此列表，其他人也可以自由订阅。

如果补丁提交者改变主意不想进行审查，他们应通过在审查弹出菜单中选择空白选项来清除 review 标志。

有关如何准备代码更改的更多详细信息，请参见本网站的其他部分。

审查提议的修复方案

审查者将仔细阅读每个提议的补丁。如果补丁已准备好提交，审查者会将 review 标志更改为 +。为了清晰起见，审查者在批准补丁时添加评论会很有帮助。通常，此评论只是“r=me”，这只是“我已审查此补丁，它已准备好提交”的简写。

补丁可能因各种原因尚未准备好提交。错误修复可能不正确。补丁中包含的测试用例可能不足。错误修复和测试用例可能没问题，但编码风格可能不正确。审查者应始终详细解释补丁尚未准备好提交的原因，以便提交者或其他人可以修改补丁。

当提交者提出更新的补丁时，他们应勾选先前版本补丁上的 obsolete（已过时）复选框。这会使其在错误主页上的附件列表中显示为划掉。在将旧补丁标记为 obsolete 的同时，提交者还应清除 review 标志。在一个完美的世界里，这会自动发生，但目前尚未实现。

提交补丁

补丁获批后，拥有 WebKit 源代码仓库提交权限的人员将把补丁提交到源代码仓库中。提交者应将错误状态更改为 FIXED（已修复）；通常此时受分配人保持不变。

所有拥有提交权限的人员都应订阅 webkit-reviews 邮件列表，这样他们将在补丁获得批准并准备好提交时收到电子邮件。如果一个已批准的补丁长时间未提交，补丁提交者可以向此邮件列表发送电子邮件请求状态。作为最后手段，补丁提交者可以直接联系审查者。由于每个人都日程繁忙，在补丁审查和提交方面出现一些延迟是不可避免的。

如果错误报告中提到同一错误在另一个内部系统（例如苹果的内部 Radar 系统）中也有体现，并且提交错误的人员可以访问该系统，那么提交错误的人员也应在内部系统中相应地更改错误状态。对于 Radar 错误，新的适当状态应为“软件已更改/集成”。

验证修复

在错误的补丁提交后，修复仍需要验证。通常此步骤由最初提交错误报告的人员完成。如果提交者不可用或认为他们无法验证修复，则验证步骤可以由任何拥有错误编辑权限且足够熟悉最初报告问题以自信地进行测试的人员完成。请注意，一旦错误处于 FIXED 状态，受分配人就无法再更改。这意味着需要验证的错误通常不会分配给预期验证错误的人员。

要验证错误修复，请构建并运行包含该修复的源代码，并检查最初报告的问题是否仍然存在。如果问题不再发生，请将解决方案更改为 VERIFIED（已验证）。如果问题仍然存在，请将解决方案更改为 REOPENED（重新打开）并将其分配给提交补丁的人员。

关闭错误

已修复的错误将保持 VERIFIED（已验证）解决方案，直到包含该修复的 WebKit 版本公开发布。此时，解决方案更改为 CLOSED（已关闭）。2