-WebKit-中Bug的生命周期

介绍

本文描述了WebKit开源项目中bug的生命周期。在大多数情况下，这与任何Bugzilla项目中bug的生命周期相同。Bugzilla网站还包括Bugzilla的更多详细信息。

新的-未确认的Bug

一个新的Bug开始于未确认的状态，通常在某个组件中出现新的Bug，但是在最初的Bug报告中，一些Bug被赋给某一个组件。

确认Bug

接下来就是拥有确认Bug权限的人员去Review那些未确认的Bug，决定是否向前推进。

• 如果确定错误与先前报告的错误具有相同的原因，则将解决方案更改为DUPLICATE。

• 如果最新的源代码中似乎不存在该bug，则将解决方案更改为WORKSFORME。

• 如果错误没有描述WebKit的问题，则解析更改为INVALID。

• 在极少数的情况下将解决方案更改为WONTFIX，但需要指出一个具体的原因（通常这将是一个跨浏览器兼容性问题）。

• 如果错误没有足够的信息来继续，则添Comments/questions。

• 如果该bug在OSX上的最新源代码中是可复制的，或者有足够的信息可以向前推进，则状态更改为“新”。如果该bug在最新的源中不可复制，但似乎只发生在PlatformOnly字段中声明的平台上，则添加PlatformOnly关键字并将状态设置为NEW。在更改状态的同时，如果需要，还应该将组件设置为比新bug更具体的组件。

分析Bug

每个bug最初都分配给指定为组件所有者的人。受让人在阅读了bug并确信它代表了WebKit中的一个真正的问题之后，应该将bug状态从NEW修改为ASSIGNED。如果他们对此不满意，他们应该执行上面“确认Bug”的一个操作。对于状态为“REOPEN”的Bug，遵循相同的过程（请参见下面的验证修复）。

被指派者代表被期望采取下一步调查或修复错误的人。如果被派遣人以外的其他人正在调查或修复错误，则应将被派遣人改为执行工作的人员。这有助于防止重复工作。添加一条注释来解释为什么要更改受让人总是很有帮助的

提出解决方案

建议的修补程序应作为新附件添加。附件应选中修补程序复选框，并将review标志设置为?。这会将补丁标记为等待审查。如果修补程序需要特定审阅者的专业知识，则提交者或其他审阅者应将请求的审阅者的电子邮件地址放在Requestee字段中。否则，此字段应留空。此时状态保持为“ASSIGNED”；在将修复签入源树之前，它不会更改为“FIXED”。

当审阅标志的状态发生更改，或者在附件的编辑表单中作出评论时，电子邮件将自动发送到webkit reviews邮件列表。评论者都订阅了这个列表，其他人也可以这样做。

审查修复

评审人员将通读每一个提议的补丁。如果修补程序已准备好提交，则审阅者会将审阅标志更改为+。为了清楚起见，审阅者在批准修补程序时添加注释是很有帮助的。通常这个评论只是“r=me”，它只是“我已经检查了这个补丁，可以提交了”的简写。

由于各种原因，修补程序可能无法提交。错误修复可能不正确。补丁中包含的测试用例可能不足。错误修复和测试用例可能很好，但是编码风格可能不正确。审阅者应该始终详细解释为什么补丁没有准备好提交，这样提交者或其他人可以修改补丁。

当提交者提出一个更新的补丁时，他们应该选中先前版本补丁上的过时复选框。这会导致它在bug主页上的附件列表中被划掉。在标记旧补丁过时的同时，提交者还应清除review标志。在一个完美的世界里，这会自动发生，但目前还没有。

提交修补程序

在修补程序被批准后，在WebKit源代码存储库中具有提交权限的人将把该修补程序提交到源代码存储库中。提交者应该将bug的状态更改为FIXED；通常情况下，受让者在这一点上保持不变。

所有具有提交权限的人都应该订阅webkit reviews邮件列表，这样当补丁被批准并准备提交时，他们将收到电子邮件。如果一个被批准的补丁没有被提交的时间似乎太长了，补丁提交者可以向这个邮件列表发送请求状态的电子邮件。作为最后的手段，补丁提交者可以直接联系审查者。由于每个人的日程安排都很忙，所以在查看补丁程序以及提交补丁程序时出现一些延迟是不可避免的。

如果bug报告提到同一个bug出现在另一个内部系统中，比如苹果的内部雷达系统，并且提交bug的人可以访问该系统，那么提交bug的人也应该在内部系统中适当地更改bug的状态。对于雷达错误，新的适当状态将是软件更改/集成。

验证修补程序

在提交bug的补丁之后，仍然需要验证修复。通常这一步是由最初提交错误报告的人完成的。如果提交者不可用或不认为他们可以验证修复，验证步骤可以由任何具有bug编辑权限的人来完成，这些人对最初报告的问题非常熟悉，有信心进行测试。请注意，一旦bug处于FIXED状态，就不能再更改受让人。这意味着需要验证的bug通常不会被分配给期望验证bug的人。

要验证bug修复，请构建并运行包含该修复的源代码，并检查最初报告的问题是否仍然出现。如果问题不再出现，请将解决方案更改为VERIFIED。如果问题仍然存在，请将解决方案更改为REOPENED，并将其分配给提交修补程序的人。

关闭Bug

FIXED的Bug经过验证的，直到包含修复的WebKit版本被公开发布。此时，解决方案改为CLOSED；

ps:侵立删