关于 Kostja 黑客攻击 MySQL 动机的评论

最近，Kostja 发表了两篇富有洞察力的博客文章，一篇关于他对当前 MySQL 生态系统碎片化的思考，另一篇关于“社区成员”贡献的代码质量。“社区成员”是 MySQL 中对非 MySQL 雇员的委婉说法。（因此，全职的 MySQL 开发者自己反而不是他们社区的成员吗？）

我想对这两篇文章发表评论，但发现 Kostja 只允许已登录的 LiveJournal 用户评论，而我不是。由于这些文章足够有趣，我想它们值得像这样在一篇新的博客文章中进行评论。

摘自“RDBMS 软件很困难”（略有调整顺序）

导致 MySQL 更改更困难的主要原因是历史遗留问题更严重，包括政治和管理方面，但在任何项目首次发布后，你都会遇到同样的情况。我说过，综合来看，当前的 MySQL 主干可能是与当前 Drizzle 一样好的重新思考起点。[…] 我并不想真正贬低 Drizzle 的重要性（最初，我很喜欢它，并且很想加入；我没有加入的原因，我刚才已经说明了）。我希望被证明是错的，但我认为它不会成为我个人愿意为其贡献的那种通用软件。

近年来，MySQL 生态系统的技术思想出现了严重的碎片化。Drizzle、MariaDB、Percona 对社区来说非常棒，但对于我们能否将 MySQL 打造成一个通用数据库平台来说，却一点都不利。我的意思是，能否让 MySQL 成为一个数据库平台，就像如今 Linux/Unix 对于操作系统一样。说实话，我一点也不确定我现在的雇主 Oracle 是否适合寻找这个圣杯。也许我们永远无法达到那个目标，至少通过这个项目是如此。

Kostja，你有这样的想法并不孤单。我认为，在审视 MySQL 生态系统时，将 Drizzle 和其他分支区分开来看是有道理的。在我看来，当 Drizzle 开始时，所有建立新分支的充分理由都存在：原始项目开发停滞不前，补丁无法流入主干，无法响应新的技术需求（云计算）……与此同时，Drizzle 的方法在短期内根本没有用。Drizzle 开始至今已有两年。他们将在今年夏天进入 Beta 阶段，甚至他们的第一个版本都没有打算涵盖整个 MySQL 领域。

这意味着即使对于 Drizzle 来说是最好的情况，短期内所有 MySQL 开发者都加入它也根本不现实。MySQL 当前有大量正在生产环境中运行的服务器安装基础。你不能对此视而不见，相反，你打造一个通用数据库的最佳选择当然总是那个已经拥有如此多用户的项目。即便如此，我认为一小群开发者创建 Drizzle 分支是有充分理由的。这样做的代价是他们基本上脱离了 MySQL/MariaDB 的开发，尽管我们之间仍然相互提供友好的支持。

所以对于你的想法，我只是想说这正是我在 MariaDB 而非 Drizzle 工作的原因。如果有一天 Drizzle “达到了目标”，时机合适时我将毫不犹豫地转移我的精力，但就目前而言，这就是我在 MariaDB 工作的原因。

至于所有其他或多或少与原始 MySQL 代码库兼容的分支，情况则不同。这主要是由于 MySQL 的组织方式：从外部看，即使我们愿意，也无法参与 MySQL 的一些基础设施，比如 Pushbuild；出于商标原因，我们不能将我们的软件包命名为“MySQL”（Percona 最先这样做了，但现在不再如此）；而且 MySQL 不会将其自身（以 GPL 发布时）纳入我们的代码，因此我们最终走向分歧。

所以从大局来看，目前有点混乱。与此同时，很高兴看到 MySQL 社区中的人们，无论是开发者还是其他人，都非常致力于继续合作，尽管存在当前的障碍。例如，我自己也不相信 Oracle 是推动 MySQL 前进的完美管家，但我也不认为 MySQL AB 曾接近完美！只要 Oracle 支付你薪水并且你可以开发 GPL 代码，确保这段代码的未来就取决于整个社区。欢迎 Oracle 贡献——他们也确实在贡献——但我们的开源数据库的未来绝不能依赖于一家公司在做什么。

然后，在“这到底是怎么回事，竟然能接受”一文中，Kostja 对一个贡献的补丁的低质量表示遗憾

一个半成品、文档不全的代码应该被接受，并期望将来会有更多补丁吗？

答案显然是“不”。一个半成品补丁应该被审查并提供反馈，以便原始开发者能够继续完善它。

不幸的是，这并没有发生在 MySQL 中。在 MariaDB 5.2 中，我们现在已经引入了多年来在 MySQL 社区中创建的许多补丁。我们不得不花费大量精力来使其达到可接受的质量。这不是一个开源项目应有的运作方式。（如果你向 Linux 发送一个低质量的补丁，Linus 不会手把手地帮你修复它。）但由于这种工作流程之前并未建立，并且许多补丁已经有几年的历史，我们将其视为一种“启动性努力”。回去找一个三年前贡献了东西的人，现在要求他们修复一些问题，感觉不太合适。即便如此，我们也不打算继续这样做，我们确实想把 MariaDB 变成一个由贡献者完成补丁的几次迭代，然后我们再提交的项目。

顺便说一句，受雇于 MySQL/Sun/Oracle 也不会神奇地让你成为一个完美无缺的程序员。在最近的合并中，我们已经开始拒绝一些来自 MySQL 的补丁，因为它们未能通过我们的审查，或者更可能因为它们在我们的自动化质量保证（buildbot）中被捕获。例如，通过包含一些 MySQL 没有的引擎，我们的测试覆盖范围比 MySQL 更广，有时能捕获到通过 MySQL 流程的错误。

最后，我想说 MariaDB 开发者（特别是受雇于 Monty Program 的那些）也并非完美无缺！我们花了些力气改进后才提交的补丁之一是 分段键缓存 (Segmented Key Cache)。但现在我们收到了原始开发者的反馈，称最终的补丁带来的性能提升不如他原始的补丁。也许我们在审查时弄坏了什么？在我写这篇文章的时候，这个问题仍在调查中。

我之所以回应这一点，是因为 MySQL 中的许多人（我说的更多可能是某些经理，而不是像 Kostja 这样的人）存在一种看法，认为非雇员根本无法产出有用的东西，而社区这种事只会分散注意力。我希望 MariaDB 5.2 能证明社区已经做出了有益的贡献，也希望将来能证明还可以做出更多。而且，无论你在哪家公司工作，时不时都会产生 bug。

RDBMS 软件很困难RDBMS 软件很困难