Tomas Vondra：Postgres 的开发会永远依赖邮件列表吗？
内容提要
Postgres是一个成功且受欢迎的数据库，但其开发过程仍然依赖于邮件列表。尽管邮件列表有一些缺点，但Postgres仍在逐渐改进开发流程，而不是完全转向pull requests。
延伸解读
邮件列表流程的历史包袱
Postgres 始于 1996 年，其开发流程深深植根于当时的开源实践，邮件列表便是典型代表。对于新贡献者而言，这种流程可能显得陌生且难以适应，因为贡献方式在项目早期就已定型，且演变极为缓慢。尽管邮件列表在早期是标准做法，但如今许多新项目已转向基于拉取请求的集成流程，这使得 Postgres 的流程不再默认。
渐进式改进而非彻底变革
尽管依赖邮件列表，Postgres 的开发流程并未停滞。项目从 CVS 迁移到 Git，开发了 commitfest 应用来跟踪补丁状态，并利用 GitHub CI 进行自动化测试。这些改进是渐进和增量的，旨在不破坏现有开发者工作流的前提下逐步优化。未来预计也不会完全转向拉取请求，而是继续以类似方式演进。
幸存者偏差与流程讨论
关于开发流程的讨论往往存在幸存者偏差，参与者多为长期开发者，他们已熟悉并适应邮件列表流程。作者本人也承认自己属于这一群体，对拉取请求工作流缺乏良好体验。因此，在考虑流程改进时，需要意识到这种偏差可能影响对问题的判断，并关注新贡献者面临的真实障碍。
依赖托管服务的风险
采用拉取请求工作流可能依赖托管服务（如 GitHub）或自托管方案（如 GitLab）。托管服务存在公司战略变化、数据迁移困难以及法律合规等风险；自托管则需自行运营，增加基础设施团队负担，且可能面临项目废弃的风险。Postgres 社区曾有过自定义 GForge 分支的不愉快经历，因此对依赖外部服务持谨慎态度。
Q&A
Postgres的开发过程为什么依赖邮件列表？
Postgres的开发过程依赖邮件列表是因为这是早期开源项目的常见做法，尽管这种方式对新贡献者来说可能显得复杂和古老。
Postgres是否会完全转向使用pull requests？
Postgres不会完全转向使用pull requests，而是会逐步改进现有的开发流程。
使用邮件列表的开发流程有哪些缺点？
使用邮件列表的开发流程可能导致新贡献者不熟悉流程，且在跟踪补丁状态方面效率低下。
Postgres在开发过程中采用了哪些新工具？
Postgres在开发过程中采用了git版本控制系统和其他辅助工具，如commitfest应用，以帮助管理补丁。
为什么新贡献者在Postgres开发中面临挑战？
新贡献者面临挑战是因为现有的开发流程复杂，且缺乏有效的补丁跟踪工具，使得参与变得困难。
Postgres的开发者对pull requests持什么态度？
Postgres的开发者对pull requests持怀疑态度，认为它们可能不适合复杂的补丁，并且不一定能吸引长期贡献者。
