2018 年 10 月 23 日，Linus Torvalds 从自我隔离中走出，从各种开发人员的 git 树中拉取了大量补丁。这是他自 2018 年 9 月 16 日以来首次出现在 Linux 内核邮件列表中，当时他宣布将暂停内核开发，以解决他有时对开发人员的严厉态度。23 日，他宣布回归，我在此总结了他的一些拉取活动后，对此进行了报道。

对于他的大多数拉取，他只是回复一封电子邮件，内容为“已拉取”。但在其中一封邮件中，他注意到 Ingo Molnar 的电子邮件存在一些问题，特别是 Ingo 的邮件客户端使用了 iso-8859-1 字符集，而不是更常用的 UTF-8。Linus 说：“在这个时代使用 iso-8859-1 而不是 utf-8 简直太奇怪了。看起来一切都很好，但如果 Mutt 有一个选项可以只以 utf-8 格式发送，我鼓励每个人都使用它，并尝试在所有地方都使用 utf-8。当人们混合区域设置等，并且链中的某个点出错时，我们遇到了太多愚蠢的问题。”

24 日，Linus 继续从开发人员树中拉取。其中之一是来自 David Miller 的一批网络更新，其中包括许多不同的人的贡献。Linus 注意到 Kconfig 规则遇到了未满足的依赖项警告，因为代码预期在 Qualcomm 架构上运行，而 Linus 没有使用该架构。他建议这只是更新代码中依赖项列表的简单问题。他还询问开发人员为什么在测试补丁时没有注意到这个问题。Kalle Valo 解释说：“主要是由于我休假造成的时机不佳。我确实进行了 allmodconfig 构建，但不确定为什么我错过了警告，kbuild 机器人也没有报告任何内容。Jeff 上周确实报告了它，但我当时正在休假，昨天刚回来，还没有时间对此做出反应。”

Linus 觉得这没问题，他说他会在修复程序可用时拉取它。他评论说：“我只是不希望我的树中有我看到的警告，这可能会掩盖我在下次拉取请求时出现的新警告。”

25 日，Linus 继续从开发人员树中拉取。在一个实例中，提出了最小工具版本的问题。Linus 倾向于支持尽可能多的普通用户，这意味着支持来自 Linux 发行版的工具版本。

为了回应一个难以阅读的补丁，Andi Kleen 建议将最小支持的 binutils 版本从 2.20 更改为 2.21，这将支持一些有用的汇编器操作码，使补丁更容易审查。Andy Lutomirski，另一位补丁审查员，表示这没问题。Linus 说

我总是投票支持“需要现代工具”，只要它不会引起问题。

binutils-2.21 现在已经有大约七年的历史了，但真正的问题是发行版实际交付的版本是什么。我不希望人们为了构建内核而不得不构建自己的 binutils。

通常是一些老旧的企业发行版卡在旧版本上。有人知道吗？

Andy 回复说：“CentOS 6 是 binutils 2.23。CentOS 5 已经 EOL。RHEL 5 具有“延长生命周期”，这意味着它已正式僵尸化，付费客户仍然可以下载（不受支持的）软件包。SLES 11 是 binutils 2.19，这已经不受支持了。SLES 12 是 2.24。所以我猜我们没问题，我们可以将要求提升到 2.21。”对话就此结束。

回到 10 月 23 日，Linus 宣布他返回邮件列表和内核开发

所以很明显我已经开始为合并窗口拉取东西了，我注意到 Greg 在过去几周这样做时，他有一个习惯（或自动化）在拉取时发送 Ack 电子邮件。

事实上，当他给自己发送虚假的拉取消息时，我对它们不在那里做出了反应。因为他没有给自己发送一个已拉取的确认信息 ;(

实际上，我开始说“我会尝试做同样的事情”。

但在实际开始拉取之后，我注意到它与我的传统工作流程不太协调，所以我最终没有这样做。

特别是，问题在于每次拉取后，我都会在拉取真正“最终”之前进行构建测试，当构建测试正在进行时（当我在路上并使用我的笔记本电脑时，这需要几分钟到一个多小时），我会继续查看*下一个*拉取（或其中一个待处理的拉取）。

因此，当构建测试完成时，原始拉取请求早已消失 - 已存档并完成 - 我已经继续前进。

最终结果：回复拉取请求对我的流程来说有点不方便，这就是我没有这样做的原因。

相比之下，这封电子邮件是在“事后”编写的，只是通过查看 git 树来编写脚本“我为谁拉取并推送出去”。这很糟糕，因为这意味着我根本没有回复原始电子邮件，因此丢失了其他人和邮件列表的任何抄送。这实际上可以通过简单的自动化做得更好。

所以我有一些选择

- 就是不做

- 在验证和最终确定之前确认拉取请求。

- 在执行拉取时开始回复，将电子邮件在单独的窗口中打开，继续处理下一个拉取请求，然后在构建测试完成后，我将开始下一个拉取请求，完成旧的待处理电子邮件。

显然，第一个选项是最简单的。我不确定 Greg 做了什么，在后来的 rc 中，这可能无关紧要，因为可能根本没有任何重叠操作。

因为是的，第二个选项在大多数情况下可能都可以正常工作，但如果出现问题，我的拉取可能实际上不是最终的 *如果* 出现问题（坏可能只是“哎呀，我的测试显示语义冲突，我需要修复我的合并”到“我将不得不更仔细地查看该警告”到“呃哼，我将完全撤消拉取，因为它最终被破坏了”）。

第三个选项可以可靠地工作，并且不会出现“哦，我的拉取只是暂定的完成”问题。它只是在我的工作流程中增加了一个烦人的来回切换。

所以我主要是 ping 那些我已经拉取过的人，看看人们实际上有多 _在意_。是的，确认很好，但是人们是否足够在意，以至于我应该尝试进行工作流程更改？传统上，你可以看到我已经从看到最终结果中拉取了，当它实际到达公共树时（这又比上面的步骤更进一步 - 我在每次拉取之间进行构建测试，但我通常倾向于批量推送最终结果，通常每天几次）。

评论？

Linus Walleij 赞赏了 Linus T 的工作流程描述，并表示他不需要确认电子邮件。但他问道：“你难道不能工具化一些东西，在事后自动发送邮件吗？Greg 的‘通知’，例如补丁 so-or-so 已应用，显然是由脚本在他应用并测试了一堆补丁后自动生成的，我认为拉取请求也应该可以做到同样的事情？只是在你完成一天的工作后运行一些东西来完成交易。”

Linus T 回复说

一定程度的简单/愚蠢的自动化是可能的。这就是这封电子邮件中的参与者列表的生成方式，但我使用的脚本实际上是一个非常垃圾的单行脚本，恰好在大多数情况下都有效。

它只是做了我通常的“mergelog”（这有点像“git shortlog”，它是一个脚本，只是为了获得我的合并摘要而不是一般的 git 日志），然后它使用该查找结果通过仅匹配提交者来查找电子邮件地址。

但它已经坏到几乎没用的程度，原因有几个

- 我的 mergelog 名称不一定与 git 历史记录中的任何名称匹配。

例如，当我从 Greg 那里合并时，Greg 使用“Greg KH”，因为我很懒，并且觉得我不想错误地输入他的名字，我已经输入过太多次了。但在实际的 git 历史记录中，他使用完整的“Greg Kroah-Hartman”，所以我的愚蠢脚本会把他搞砸。

另一方面，具有复杂字符的人员会从他们的电子邮件或标签中的签名中复制粘贴他们的姓名，有时这些姓名也不匹配。

- 有些人在 git 历史记录中使用一个电子邮件用于“官方”目的（即公司电子邮件等），但实际上倾向于*使用*另一个电子邮件（因为有时公司电子邮件速度慢和/或损坏）。

- 它不会获得通常的邮件列表抄送等，而这些可能是最重要的。毕竟，我就是这样看到 Greg 的回复的。

所以我感觉自动化模型不太好。回复应该发送到实际的拉取请求，而不是 git 历史记录。想要仅仅是 _那个_ 的人已经可以自动化 git 历史记录的事情，甚至无需我做任何事情，无论是自己编写脚本还是通过对内核提交邮件列表进行一些过滤。

所以我碰巧将自动化模型用于此电子邮件线程，但我认为它实际上是所有世界中最糟糕的。

Willy Tarreau 也回复了 Linus T 的原始电子邮件，他说他认为确认电子邮件不是必要的，并且大多数开发人员只是想确保 Linus T 实际收到了拉取请求。但 Willy 建议，如果在实际从树中拉取后，Linus T 改变了主意并还原了更改，则发送电子邮件。在这种情况下，发送给该开发人员的电子邮件将很有用。

Linus T 回复 Willy，说这实际上是他正常的工作流程——仅在尝试拉取但后来决定还原更改的情况下发送电子邮件。他说，“而且那封电子邮件不会消失，所以如果我首先发送一条‘已拉取’确认消息，然后发生了一些不好的事情，我取消拉取它，我仍然会发送第二封电子邮件，说‘哦，糟糕，毕竟没有拉取’。”

Ingo Molnar 也回复了 Linus T 的原始电子邮件，说他使用了 Linus T 提出的选项之外的另一个选项。他解释说

我使用“零收件箱”邮件阅读，从后到前，这样我可以通过简单地将邮件标记为未读来“延迟”对拉取请求或补丁的回复。然后，当我推送经过测试的树和补丁时，我会去处理 mbox 的尾部，通常是几个条目。（对于补丁，我什至不必做任何事情，因为通知是自动的，当我看到 tip-bot 通知时，我会将补丁标记为已读。）

它仍然是一个单独的工作流程步骤，但比推迟的电子邮件或单独的电子邮件窗口更容易管理，这些窗口不可避免地会在每隔几周的浏览器事故中丢失，并且在主要工作流程中也不够突出。

对于您收到的邮件量来说，可能不是一种实用的方法。

Ingo 还提到，他个人感觉他不喜欢收到确认电子邮件。他同意收到电子邮件会更方便，但他说，“这不是一个重要因素；我认为您的工作流程（这是一个单线程）的效率应该是这里首要考虑的问题。”

Boris Brezillon 也回复了 Linus T 的初始帖子，说他确实更喜欢收到确认电子邮件。他补充说，“我不在乎此通知是以回复原始电子邮件的形式发送还是在单独的电子邮件中发送。”他还说，他认为这样的事情将是自动化的，他总结说，“这只是一件好事，如果自动化太复杂，我可以不用它。”

Mark Brown 也回复了 Linus T 的初始帖子，说他不需要确认电子邮件。事实上，他说，“我第一次收到 Greg 发给我的确认时有点震惊 - 你的通常工作流程是，如果有任何邮件，那就意味着有问题。”

Takashi Iwai 也回复了 Linus T 的初始帖子，说他确实感谢确认电子邮件 - 不是因为它们表明补丁已被接受，而是仅仅表明拉取请求已被收到。

Greg Kroah-Hartman 也回复了 Linus T 的初始帖子。当 Linus 离开时，Greg 一直是接受开发人员拉取请求的人，他总是给出确认电子邮件，这就是 Linus T 考虑做同样事情的原因。Greg 对 Linus T 说

我也有同样的问题，因为我运行了完整的构建并且不得不等待结果。但我收到的拉取请求数量要少得多，所以我只是将它们全部转储到一个文件夹中，然后在测试结果返回时做出响应。

所以我和你遇到同样的问题，但是你有更多的请求要处理，抱歉。

Kirill A. Shutemov 也回复了 Linus T 的初始帖子，加入了推荐自动化解决方案的合唱。他建议将电子邮件 Message-ID 字段包含在合并提交消息本身的文本中。然后，工具可以轻松地提取 Message-ID，从电子邮件存档中提取抄送列表，并将确认电子邮件发送给该列表中的每个人。Mark Brown 建议简单地将抄送列表也包含在提交消息中，这样工具甚至不需要查询邮件列表存档。

但 Linus T 说他不想在自动化电子邮件方面走得太远。他回复 Kirill 和 Mark，说

我想我只会尝试“在开始拉取时确认”模型，看看效果如何。也许我考虑得太多了。

如果事实证明在一切都通过后再确认会更好，我可以轻松地对“发送给我的消息，但我已存档且未回复，并且其中包含‘git pull’”的消息进行电子邮件过滤。

我使用电子邮件过滤器来精确定位最初的拉取，我可以只使用电子邮件过滤器来精确定位我已经处理过的拉取请求。

因此，Linus 似乎已决定走一条路，但在另一封电子邮件中，他说，“我开始认为邮件列表自动化确实是一个好主意”，他继续说，“我认为最好有一个通用的模型，用于‘当 XYZ 命中 git 树 ABC 时给我一个触发器’，人们可以普遍做到这一点，*但是* 我认为‘扫描邮件列表以查找常规拉取请求’实际上会更好。”

他继续说

如果“通知”真正做了正确的事情，并创建了实际的电子邮件跟进，具有正确的收件人/抄送和主题行，而且还有正确的“References”行，以便它实际上也被正确地线程化，那就更好了。这意味着它真的应该集成到邮件列表本身中。但我不知道整个 lkml 存档机器人对于此类事情有多灵活。但我假设您对 lore.kernel.org 的新消息传入有一些钩子？

讨论到此结束。

因此，没有提及行为准则，也没有提及他如何利用离开内核开发的时间。他只是专注于赶上合并进度并讨论可能的工作流程更改。当真正的冲突出现时，情况会变得更加有趣，因为这是不可避免的。有各种各样的安全和其他实现主题通常会导致冲突，更不用说开发人员在现有代码的行为以及修复问题的正确方法上存在分歧的情况。

注意：如果您在上面被提及并希望在评论区上方发布回复，请将包含您的回复文本的消息发送至 ljeditor@linuxjournal.com。