补丁处理 ​

注意：自 2014 年初引入 Gerrit，以及随后在 2020 年中迁移到 GiLab 以来，此流程已经发展到超出本阶段的程度，请参见 Development/SubmittingPatches。

简介 ​

Wireshark 核心开发者最近的一次讨论得出结论：当前的补丁处理策略仍有改进空间。为了实施策略变更，本页面会收集所有相关信息和任务，直到基础设施和文档中的所有相关变更都已完成。

• 补丁处理
• 简介
• 背景
• 任务
• 已完成的任务
• 讨论

背景 ​

邮件列表里有很多人在疑惑他们的补丁是否被忽略了。这首先不好，因为它会让邮件列表变得杂乱；但更关键的是，它会让开发者群体产生不满。如果你不得不提交或催促自己的补丁五次，你就会开始觉得自己的工作没有受到重视，也觉得根本不值得费力把它提交到上游。是的，我们都知道并不是这些工作不受重视——我这里说的是开发者的视角。

人们认为，首先将补丁提交到 Bugzilla 会带来以下优点：

• 更容易发现某个补丁是否被遗漏——你只需搜索新 bug 即可。在邮件列表中查找被遗漏的补丁很困难，尤其是在你离开几天后再回来查看时。
• 它会把关于某个特定补丁的讨论集中在一个地方；你可以看到补丁如何演进，以及任何评审评论；邮件列表中的线程机制在这方面严重不足。
• 甚至可以在 commit comment 中放入 bug 编号，这会让未来的维护者能够看到补丁历史——在试图理解某段特定代码为何以这种方式编写时，这可能非常有用。
• 它可以让邮件列表用于讨论解决问题的方法、总体思路等，而不是被“这是 foo 的补丁”；“真的，这是 foo 的补丁”；“看在上帝的份上，难道没人评审我的补丁吗”；“已签入，谢谢”这类内容填满——坦率地说，这些只是噪声。

任务 ​

已完成的任务 ​

• 修改 Bugzilla，使其能够处理补丁提交和评审请求。

• 文档：以下内容都说你可以或应该把补丁发送到邮件列表；它们需要更新为说明你应该把补丁发送到 bugzilla 并将其标记为需要评审：

• http://www.wireshark.org/develop.html

• 开发者指南更新（http://www.wireshark.org/docs/wsdg_html/#ChSrcSend）

• SendingFilesToWireshark

• 需要向 wireshark-dev 发送一封电子邮件，宣布流程变更并要求人们以后创建 bug。

讨论 ​

导入自 https://wiki.wireshark.org/Development/PatchHandling ，时间为 2020-08-11 23:12:58 UTC

相关 Wireshark Wiki 页面 ​

• Wireshark Wiki 首页Home · 入门与使用
• Development/SubmittingPatchesDevelopment/SubmittingPatches · 开发与扩展
• SendingFilesToWiresharkSendingFilesToWireshark · 全量归档