首先，我要说我犯了一个错误，这个错误导致到目前为止所有的指标博客文章都使用了错误的数据。作为我们开放价值观的一部分，我将在这里对这个问题进行事后分析。
指标生成
在深入探讨问题之前，我首先需要提供一些背景信息。提交指标是使用一个名为“gitdm”的工具生成的，这是一个“Git 数据挖掘器”，旨在为 Linux 内核生成提交统计信息。我们的这个工具分支位于 metrics 仓库中，其中包含了一些更适合 MariaDB Server 需求的自定义设置。
gitdm 的工作方式是，你需要生成一个 git 日志并将其导入到该工具中，工具将根据这些数据生成指标输出文件。然后我们有自己的脚本来自动完成这一切，以针对 MariaDB Foundation 生成的 MariaDB Server 指标所需的特定时间段。
问题所在
在生成要处理的 git 日志时，重要的是要包含所有活跃开发分支的提交。这是因为有些修复可能包含在某个版本中，而对于后续版本则不是必需的。当您检索多个分支的提交日志时，Git 非常智能，可以对已合并到不同分支的提交进行去重。这意味着进入 MariaDB 多个版本的代码更改应该只计算一次。
最初设置并试用 gitdm 时，我在 git 上使用了 --all 参数来检索所有分支的提交信息。然后将其包含在脚本中。我忽略的是，这对于 MariaDB Server 来说有点太广泛了。
MariaDB Server 的 git 树还包括 MariaDB 开发人员创建的功能分支以及预览分支。此外，--all 参数会拉取 git 标签以及几乎所有可以被视为提交的内容。
几周前我意识到了这个错误，通知了 MariaDB Foundation 的首席执行官，并估计错误率应该在 5-10% 左右。上周我进行了修正，使得脚本只使用了活跃开发分支（名为 10.0 – 10.12 的分支）的提交。在此基础上，我能够找出问题的严重程度。
修正
我对我 2019 年的估算偏差不大，错误率大约是 13%。不幸的是，随后几年的数据情况变得更糟。
| 年份 | 错误率 |
|---|---|
| 2019 | 13.2% |
| 2020 | 28.5% |
| 2021 | 34.4% |
| 2022 | 46.2% |
然后我调查了错误率如此之高的原因，发现了两个原因，一个在意料之中，一个在意料之外。
意料之中的原因是由于尚未合并的功能分支。MariaDB 中有大量的正在进行的开发工作。其中一些已经持续多年，但有些被搁置了。可以预期，随着时间接近当前，正在开发中的功能数量会增加。
至于意料之外的原因，这与预览分支有关。例如，有一个名为 preview-10.11-preview 的分支，它与 10.11 有不同的历史记录，尽管包含许多相同的提交。这意味着预览分支中的许多提交被重复计算了。由于 10.11 和预览分支是更近期的分支，因此可以推断，随着时间接近当前，这也会导致更高的错误率。
这第二个原因实际上花了一些时间才弄清楚。这是因为需要多次深入研究 git 日志中那些意料之外的差异。然后我不得不深入追溯每一个差异的历史和起源，才能找到问题的根源。
从中得到的教训
有句老话叫“验证你的输入”。在这个案例中这句话非常正确。我未能充分验证 gitdm 的输入，以至于没有发现我犯的错误。话虽如此，当发现错误时，我立即提出了问题并进行了全面调查。
我已经修正了 metrics 仓库中的脚本。如果你足够有兴趣运行它们，它们已经能够生成更准确的指标数据。在更可能的情况下，你可能期望我们提供修正后的数据。我请求你耐心等待我们 12 月份的下一篇贡献指标博客文章。届时我们将提供有关即将发布的版本的新内容。