LWN：PostgreSQL 的 commitfest 讨论日志！
共 3161字，需浏览 7分钟
· 2021-09-01
关注了就能看到更多这么棒的文章哦～
PostgreSQL's commitfest clog
By Jonathan Corbet
August 12, 2021
DeepL assisted translation
https://lwn.net/Articles/865754/
虽然人们很容易将限制自由软件项目的主要因素归结到开发人员的数量上去，但事情的真相其实是（除了那些特别小的项目外）最稀缺的资源是 review 人员的时间。很多人都喜欢写代码，但很少有人能抽出时间来仔细检查别人的 patch。自由软件的众多项目上已经采取了多种不同方法来解决 review 问题。PostgreSQL 开发社区目前正在跟繁重的 review 工作搏斗，并考虑相应地改变它的 commitfest 过程。
review 相关的一个困难在于文档记录，因为 patch 必须要与它们的 review 进度一起来合并跟踪。一些项目，比如 Linux 内核，就采取了分布式的方法，review 状态在 patch 本身中进行记录跟踪，子系统维护者需要来负责确认哪些 patch 已经准备好可以合并了。当然，PostgreSQL 的开发者更愿意把这些信息保存在一个中心数据库中。基本上每隔一个月，会把那些尚未完成的 patch 集中起来，进行为期一个月的 commitfest，在此期间大家会对每个 patch 的命运做出决定。每个 commitfest 都有指定一个管理员，负责确保在 commitfest 结束时所有 patch 都得到了处理。
当然，这是人们期望看到的结果。而正如 Simon Riggs 最近在 PostgreSQL Hackers 邮件列表中指出的那样，实际上有很多 patch 在队列中徘徊，没有得到明确的决定。这很可能是由于缺乏 review，或作者没有回应等原因造成的。Riggs 指出，计划于 9 月举行的 2021-09 commitfest 活动中，有 273 个 patch 在排队中（后来增加到 279 个）。"其中，大约 50 个 patch set 已经等待了一年以上的时间，大约有 25 个 patch set 已经等待了超过两年"。Riggs 说，社区一直在努力推进，希望能在每次 commitfest 期间把队列清空，但仍然出现 "已经溢出" 的情况。
看一下过去的 commitfest 的历史（可以在 commitfest.postgresql.org 上查看到），就会发现很多 patch 得到的处理意见就是推迟到下一次 commitfest。最近结束的 2021-07 commitfest 上 review 了 342 个 patch，其中 233 个（略高于 2/3）被推后到下一次 commitfest。基于比率如此之高的事实，人们所期望的能真正清除干净 commitfest 这个队列的愿望，充其量只能算是一个愿景了。
在 PostgreSQL 项目中，一直都存在一个期望，那就是提交 patch 来加入 commitfest 的开发者，都应该花时间 review 其他人的 patch，最好还是一些复杂程度相似的 patch。理论上来说这样就可以平衡提交者和 review 者的数量了。但实际上，这个理念并没有很好地实现。几乎可以肯定的是，其中一部分原因是一些 patch 提交者从来没有履行过自己的职责，毕竟大家都很忙。commitfest 管理员的工作之一就是鼓励开发者进行 review。不用说，这个任务比起 patch review 来说更加无趣了。在讨论中，Noah Misch 提出了一个明显偏技术的解决方案：在数据库中跟踪每个提交者的 review 数量，明确列出那些没有达到要求的人员。但是，正如 Tomas Vondra 所指出的，对于什么样的工作算是 review，以及怎么样才算是同等复杂度等等，这些都是很主观的问题。
不过，人们完全遵守这个规则，问题似乎也不可能完全消失。许多 patch 都需要多个 reviewer 的意见。它们也可能会经历多次 review 过程，并不断针对反馈意见进行修改。因此，需要 review 的数量肯定会大大超过人们提交的 patch 数量。
Bruce Momjian 认为，在去年出现问题的一部分原因是因为完全没有举行面对面的开发者会议。Greg Stark 同意："每年都有一些特别有争议的 patch，一直等到面对面的会议上大家不得不马上决定的时候才得到处理。不过他也指出，这类 patch 的数量并不足以解释目前积压 patch 的规模。Michael Banck 建议举行虚拟会议来对 patch 作出决定。现在很少有开发者会非常希望举行更多的在线会议，但确实可能有足够的人被说服来参加会议，从而能产生一些进展。
几乎每个人都同意的一点是，从一个 commitfest 滑到另一个 commitfest 的 patch 中，很多根本不应该出现在那里。如 Tom Lane 所说：
作为一个社区，我们并没有坚定的意志去拒绝 patch。我认为现在的情况是，有些开发者看到一些 patch，就想 "我不喜欢这个方案，我得去做一些设计得更好的 patch"，然后它就一直滑到下一个 commitfest。
Robert Haas 也表达了类似的观点：
我认为[Commitfest 管理员]对那些没有真正产生进展patch的来回反复一直怯于叫停。如果一个 patch 在过去的某个时间点经过了 review，举例来说已经又有一个月过去了，而现在我们正在开始或结束一个 CommitFest，那么这个 patch 就应该被关闭。否则，CommitFest 就会永远被占满，总是那么杂乱无章。
想通过提高项目来关闭这些没有进展的 patch 的权利，这可能并不容易。不少人同意应该由 Commitfest 管理员来做这个决定。Riggs 建议，只允许管理员推后占比 50% 的 patch。但 Lane 指出，只有那些 "足够自信和足够资深" 的管理员才敢于 "终结那些看起来不会有什么进展的 patch"，他还说无论如何这也许都不应该是 commitfest 管理员的工作。当然，在一个月的时间里要让几十个提交者感到失望（这是必然的，只要听听他们的看法就知道了）会让这个 commitfest 管理员的工作更加不讨好。
还有一个想法也被人们几次提出过，那就是对 patch 要限制一下在它被删除之前可以经过的 commitfest 的数量。这种方法的好处是来说比较相对自动化，算是个客观标准。也就不需要有人跳出来做恶人，决定去拒绝这一大堆的 patch。这也会给那些没有人关心的 patch 带来一个比较自然的终结。
讨论结束后，暂时没有得出任何可行的结论。也许这个问题也会被推迟到下一次 commitfest 来决定。但这次讨论至少可以激励一些开发者把更多的时间放在清理队列和减少积压上，至少在短期内是这样的。从长远来看，PostgreSQL 将不得不继续忍受 reviewer 资源非常短缺的事实，这跟许多其他项目没有什么两样。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～