LWN: 使用lei来深入查询社区lore数据！

关注了就能看到更多这么棒的文章哦～

Digging into the community's lore with lei

By Jonathan Corbet
December 13, 2021
DeepL assisted translation
https://lwn.net/Articles/878205/

电子邮件（Email）现在很多人已经认为是一种前景黯淡的技术了，因为它速度慢，容易伪造，而且充斥着大量的垃圾邮件。现在的孩子们不愿意使用 Email，对许多人来说它已经失去了过去的吸引力。但是，现在许多开发项目仍然在依赖 email，也还有众多的不是开发的工作也仍然在应付大量的邮件。虽然 forge 类型的开发网站展示了一个可能可以淘汰电子邮件的工作方式，但并不是未来唯一正确的路径。如果可以在电子邮件的基础上建立新的结构去解决它的一些最致命的缺点、同时又保留许多项目中都在依靠的那些优点，这个未来是不是很美好？Konstantin Ryabitsev 最近推出的 "lei" 系统就是希望能展示一个这样的未来。

早在 1997 年，我们创建 LWN 的最初动机之一就是为了能让读者们不用去做逐条阅读 linux-kernel mailing list 的不可能完成的任务。毕竟，那个列表每天都会收到的邮件数量都能达到 100 条这么多信息，正常人都不会想去阅读这么多的内容。大约 24 年后，情况发生了变化：linux-kernel 现在每天收到超过 1000 条信息，还有其他的几十个非常繁忙的针对内核相关讨论的邮件列表。针对这么多的信息进行阅读时，很容易就错过其中重要的邮件。甚至很少有开发者尝试去阅读这么多内容。

虽然各个邮件列表上的大部分邮件很快都会被人们遗忘，但其中一些信息具有长久保存价值。这意味着需要有好的存档方式（good archives are needed）。在内核项目开发历史中大部分时期并没有这样的档案。大多数邮件列表中确实是有存档的，但它们分散在各处，可靠性也各不一样，还难以搜索，通常也都是不完整的。直到几年前 Ryabitsev 才把搭建了 lore.kernel.org，成为了解决这个问题的一个更好的方案。通过使用了 public-inbox 这个便于搜索的归档系统（archiving system）基于来自众多地方的内容建立起完整的存档，并将大多数内核相关的讨论邮件列表都归档，Ryabitsev 就这样创建了这一服务，并迅速成为社区内一个不可或缺的资源。

Lei（代表 "本地电子邮件接口"，local email interface）同样来自 public-inbox 这个社区。它可以跟 lore 很好地配合起来，于是 Ryabitsev 就把整个系统称为了 "lore + lei"。创建这种组合，是希望能创造一种处理电子邮件的新的方式，使开发者能够在不订阅邮件列表的情况下来看到他所感兴趣的信息。

Public-inbox 是基于一些很有趣的想法的，比如使用 Git 来存储档案内容本身。不过，它之所以能真正成为有价值的服务，关键是它使用了 Xapian 来实现了快速且专注（focused）的搜索功能。所谓的快速，是它允许在电子邮件存档的数百万条邮件中提供近乎即时的搜索。例如，这个查询条件（https://lore.kernel.org/all/?q=dromedary ）可以立即告诉我们 "dromedary" 一词在 lore 的所有邮件列表存档数据中被使用了 30 次。

这个搜索机制跟其他众多电子邮件客户端中的搜索机制并不相同，因为它专门实现了在技术讨论邮件列表中许多有用的搜索条件（term）。因此，当搜索 "dromedary "时，会看到出现该词的地方，而 "nq:dromedary "则只会显示那些不在回复的邮件中引用原文的位置。这就把命中词条数量降低到了 13，并且不会遗漏任何一个原始邮件中出现的这个词。它还可以专门针对一些 message header 位置进行搜索，或者搜索被 patch 修改所影响的文件名、被 patch 改变的函数名，等等等等。详情可以在 https://lore.kernel.org/all/_/text/help/ 这里看到。

简而言之，创造 lei 的目的是希望利用 public-inbox 内置的搜索功能来为开发者提供精心过滤过的邮件列表内容。可以给它提供一个搜索条件，然后生成一个 mailbox，用户从而可以使用自己喜欢的客户端来浏览这个 mailbox 的内容了。举个例子，我们可以使用下面这个 query，它出现在 Ryabitsev 在 11 月宣布 lei 的那封介绍邮件之中：

lei q -I https://lore.kernel.org/all/ -o ~/Mail/floppy \
  --threads --dedupe=mid \
  '(dfn:drivers/block/floppy.c OR dfhh:floppy_* OR s:floppy \
  OR ((nq:bug OR nq:regression) AND nq:floppy)) \
  AND rt:1.month.ago..'

这个查询条件是想获取可能与内核中 "至关重要的” 软盘驱动的维护者有关的所有电子邮件。它寻找的是全部满足如下条件的邮件：

• 影响了 floppy.c 的 patch（dfn:drivers/block/floppy.c）
  

• 所有修改了 floppy_ 开头的函数的 patch（dfhh:floppy_*）。
  

• 邮件 subject 中含有 "floppy" (s:floppy)
  

• 所有出现在不是引用文本位置的 "floppy " 并且提到了 "bug" 或 "regression" 的邮件（(nq:bug OR nq:regression) AND nq:floppy)
  

这个搜索条件仅仅查询过去 1 个月时间发送的邮件。lei 命令会进入 lore 并在所有 mailing list 上进行这个搜索、收集查询到的邮件，并将其存储在 maildir 文件夹 ~/Mail/floppy 中。然后用户就可以使用自己最顺手的工具来处理该文件夹中的邮件了。

Lei 会记住这个搜索条件，所以以后希望更新这个文件夹来获取最新查询结果的时候，只需要简单地发出 "lei up" 命令就好了。正如后来的 https://lwn.net/ml/workflows/lorelei.part2.202111121411.sznnvkvcywfbdghl@meerkat.local/ 这篇文章所描述的，用户也可以要求 lei 将检索到的邮件存储到远端的 IMAP 服务器上，而不使用本地 maildir 文件夹。

这个工作的目的非常明确：它可以让内核开发者能轻松获取到他们感兴趣的那些邮件，而不需要订阅若干个每天有大量邮件的 mailing list。没有一个开发者能够做到订阅所有那些可能会出现自己关心内容的邮件列表。有了 lore+lei，他们甚至没有必要再去查找所有需要订阅的邮件列表了。对于许多用户来说，这个做法也可以使电子邮件更加可靠。例如，此时就有一个正在进行中的关于将内核列表的邮件传递给 Gmail 用户时出现问题的抱怨。使用 lore+lei 就可以完全解决这些问题。

从某种意义上说，lei 遵循了我们在互联网的其他地方所看到的一些特征。我们之中那些多年前就看着 WWW （World Wide Web）发展到如今的人，都会记得那些希望给所有一切建立索引所做的无数努力。例如，雅虎就是从一个网络分层目录开始起家的。一段时间后，人们发现这种努力已经不可能给出有用结果了，而搜索才是在网上寻找东西的正确方式。lei 的出现也就是在说明，电子邮件讨论也是有这样的特征的。以前这种将我们的讨论按照主题来组织成邮件列表的方式已经支持了我们多年的开发，但现在这种方法现在越来越力不从心了。

这个道理如果成立的话，也许现在是时候忘记所有这些邮件列表，而只用搜索来取代了。作为朝这个方向迈出的一步，Ryabitsev 为所有 patch 创建了一个邮件列表。所有的 patch，无论它们是针对哪个子系统的。我们鼓励开发者要将他们的 patch 发布邮件也抄送这个邮件列表。这样任何对某些特定 patch 感兴趣的人就都可以使用 Lei 这样的工具来过滤掉其他的 patch 了。

当然，这里有可能会让我们失去那些不经意看到不在我们搜索目标之内、但是却是很有意思的电子邮件的这种惊喜。如果 lei 进一步将内核开发者们隔离在他们自己的小天地里，那么可能会对整个内核开发产生不利影响。多个子系统之间的讨论可能会变得更加困难，而且开发者可能会不再知晓项目中其他地方在发生什么事情。在更广泛的世界中，filter bubbles （译者注：这里意思是说使用过滤条件之后把自己的关注内容局限在一个泡泡之内，不知道泡泡之外的精彩世界）已经是一个现实问题了，它们可能会使大型自由软件项目也更难维持住凝聚力。

然而，这样的世界听起来对那些希望广泛展示社区中发生的事情的新闻网站来说是一件大好事，所以也许这并不完全是一件坏事。

最后，这个方向中还有一个值得思考的问题。lore+lei 中实现的功能本身就非常有用，但人们也可以说，它实际上只是一个数据库层，可以作为新一代协作开发工具的底层。这些工具目前还没有出现，但希望有一些开发者开始考虑如何填补这一空白。最后，这将最终为依赖电子邮件的自由软件社区提供一条道路，至少在表面上是从电子邮件迁移到了更好的工具上。基于电子邮件的基础设施可以成为一个实施细节，用户对此不感兴趣的话也完全不需要去关注。这可能会是一个值得我们大家努力的未来方向。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～