许多读者可能已经注意到，在 PostgreSQL 19 分支进入测试版阶段后，被回退的功能数量异常之多。回退一些功能并不罕见，每个开发周期平均一项可以预料。但这一次，根据统计方式的不同，约有 8 至 10 项重要功能被回退，其中一些是在测试版阶段相当靠后的时候才被回退的。作者是部分受影响功能的开发者或提交者之一，他回顾了事件经过，并给出了目前仍属初步的看法。
原因可能是多种因素的综合，每项功能的情况各不相同。作者承认代码质量可能不够好，团队的工作也可能做得不够到位。这也可能只是巧合：项目此前进展顺利，同时尝试了多项最终无法按时完成的功能。一些功能存在严重的架构缺陷，在测试版期间很难迅速修复。另一些功能则受困于大量相对无害的边缘情况问题，在过去的开发周期中，这些问题通常会在之后浮现，并在未来数年中逐步修复。
基于大语言模型的代码审查改变了这一时间表。这些问题现在被更快地发现，开发者面前摆着大约四十份缺陷报告。即使每个问题只需小幅修复，处理每个问题的固定开销累积起来，时间便不够用了。受影响的大多数功能是在此类审查工具真正有用之前编写的，因此自提交以来，实际的质量标准已经提高。作者认为，这并非“氛围编程”造成的，因为这些代码早在那种可能性出现之前就已存在。
“Vulnpocalypse”安全危机使情况进一步恶化，从四月到八月，大量资深开发者被调去修复安全问题。因此，测试版期间通常进行的额外审查与测试被削减，直到后来才得以恢复，这也解释了为何许多问题如此之晚才暴露。作者认为，若再多花约两个月时间，许多较小的问题本可以得到解决，但社区选择坚持发布日程，而非推迟。
来源: Hacker News · 由HeadlinesBriefing整理摘要