我们已经进入了十月，这意味着距离上一次指标报告已经过去了 4 个月。因此，又到了发布季度指标报告（外加一点内容）的时候了。额外的一个月是为了进行一项公告，这是本文的前提，同时也意味着我们基本与实际季度保持一致了。报告的主要变化将在本文后半部分出现，我们新增了大量关于拉取请求的数据。话不多说，让我们开始吧。
更新流程
在我们深入了解统计数据本身之前，我想稍微详细说明一下我用于更新统计数据的流程。所用的一切都位于公共指标仓库中。
我做的第一件事是运行 generate_3+year.sh 脚本来生成临时的 CSV 输出。然后我分析这些 CSV 文件，找出需要更新配置的地方。CSV 输出将包含它无法识别的人员的电子邮件地址。我会尽我所能查找这些人是谁。如果他们是已有的贡献者，但这一个新的电子邮件地址（例如 GitHub 自动生成的），他们会被添加到“别名”列表中。如果他们是新的贡献者，我会尝试确定他们的所属机构，并相应地添加到“雇主”列表中（这个列表未来应该改名）。
我还会多次深入分析 CSV 文件，尝试查找错误并相应调整配置。有些东西我可能会遗漏，有些人我可能无法正确识别。但这已经是尽我所能做到的准确度了。配置是公开的，欢迎对我的遗漏之处进行贡献修复。
最后，我会重新运行脚本以便生成这份报告。
拉取请求的统计数据相对容易，只需要一个 GitHub token 就可以执行。由于 GitHub API 的速率限制，执行需要一些时间，但这次我优化了流程以加速执行。这是必要的，因为随着收集到的新指标，我们发出的 API 调用显著增多。
GSoC 季节
对于那些还不了解的人来说，我们正处于 Google Summer of Code (GSoC) 主要开发期的末尾。这是一个 Google 支付贡献者在夏季（至少是北半球的夏季）为一个项目工作的计划。传统上，这只针对大学生，但今年向所有人开放。
这意味着因此而产生的一些优秀贡献已开始集成到代码树中。尤其是，一个大型拉取请求将 MariaDB 中的 RocksDB 更新到了最新版本（已合并到 11.3）。今年，在所有被监控的项目中，GSoC 开发者总共新增了 13,636 行代码，删除了 4,164 行代码。
不幸的是，由于一个无法在 11.3 达到预览版发布之前修复的回归问题，RocksDB 更新不得不回滚。但我们有信心将来能够将其重新引入。
Amazon 赞助
正如您在我们最近的新闻中可能看到的，亚马逊已成为 MariaDB 基金会的赞助商，因此他们在数据中被移至“赞助商”类别。由于目前类别没有日期范围，这一变化将应用于此数据快照版本中所有年份的数据。而个人贡献者的所属机构是按日期范围跟踪的。
项目跟踪
与上个月一样，我将提供每个项目的 MariaDB Plc / Foundation 贡献和外部贡献的摘要。这些项目包括：
- MariaDB Server – 服务器本身
- libmarias3 – 一个用于与 Amazon S3 及相关块存储服务交互的开源库。由 MariaDB Plc. 维护，用于 Aria 的 S3 存储和 MariaDB ColumnStore
- MariaDB ColumnStore – 一个基于列的集群存储引擎，用于 MariaDB Server。由 MariaDB Plc. 维护。
- MariaDB Docker – MariaDB Server 的官方 Docker 镜像文件。由 MariaDB 基金会维护。
- MariaDB Jupyter Kernel – 一个用于 MariaDB Server 的 Jupyter Notebook 插件。由 MariaDB 基金会维护。
- MariaDB Connector/C – MariaDB Server 的 C 客户端库。由 MariaDB Plc. 维护。
与上次相比，MariaDB Server 和 MariaDB ColumnStore Engine 的提交数量增加了约 50%。其他项目的开发速度稍慢。
| 项目 | Hackers MariaDB | Commits MariaDB | Hackers Others | Commits Others |
|---|---|---|---|---|
| MariaDB Server | 37 | 1389 | 51 | 160 |
| libmarias3 | 3 | 4 | 1 | 1 |
| MariaDB ColumnStore Engine | 16 | 231 | 7 | 11 |
| MariaDB Docker | 2 | 70 | 2 | 8 |
| MariaDB Jupyter Kernel | 2 | 12 | 2 | 4 |
| MariaDB Connector/C | 8 | 88 | -- | -- |
请注意，由于我没有注意到一位开发者使用了多个电子邮件地址，上次的 MariaDB ColumnStore Engine 统计数据将同一个人计算了两次。为了撰写这篇博文，gitdm 配置已调整以考虑此情况。
新贡献者
正如前面提到的，本次我们有一些新的 GSoC 贡献者。此外，Homebrew 项目的 Ruoyu Zhong 也贡献了一些修复，以确保 MariaDB 能继续良好地与 Homebrew 一起编译。我们感谢您的工作。
这也意味着 Homebrew 已被添加到统计数据的“Distros”类别中。
数据对比
让我们对比一下 MariaDB Server 三个月前和今天的贡献统计数据。
| 类别 | 实体 | 2023年6月 贡献者 | 2023年6月 提交数 | 2023年10月 贡献者 | 2023年10月 提交数 |
|---|---|---|---|---|---|
| MRDB | MariaDB Plc. | 25 | 706 | 30 | 1213 |
| MRDF | MariaDB Foundation | 7 | 126 | 7 | 176 |
| 提供商 | Codership | 6 | 36 | 6 | 48 |
| 赞助 | Amazon | 11 | 33 | 14 | 43 |
| GSoC | GSoC | 1 | 1 | 1 | 2 |
| 发行版 | 所有发行版 | 3 | 3 | 5 | 7 |
| 其他 | 其他人 | 17 | 65 | 32 | 109 |
| 总计 | 70 | 970 | 88 | 1549 |
备注
- 红帽在被 IBM 收购后处于灰色地带。在这个矩阵中，我们将其置于“发行版”类别下，与 IBM 和“赞助商”分开。
- “赞助商”和“提供商”类别中有更多实体，但为了简化，在本表中已将其与独立贡献者一起归入“其他”类别。
- 提交数不总是能说明全貌，一次提交可能包含一行代码，也可能包含数千行。
拉取请求
本次有趣的部分就在这里。正如之前的一篇博客文章所述，我们现在会生成关于首次有意义响应时间的统计数据。这意味着我们现在有以下统计数据：
- 新 PRs：该周已打开的 PR 数量。
- 草稿 PRs：该周新打开的 PR 中，有多少目前是草稿。
- 已关闭 PRs：该周已关闭的 PR 数量（未合并）。
- 已合并 PRs：该周已合并的 PR 数量。
- 总 PRs：截至该周末，我们总共拥有的 PR 数量。
- 仍开放 PRs：截至该周末，仍开放的 PR 总数（包括草稿）。
- 首次响应天数：对于该周打开并已获得响应的 PR，获得首次有意义响应的平均天数。
- 已响应的新 PRs：该周打开并已获得有意义响应的 PR 总数。
- 作者自行合并（无评审）的 PRs：该周打开的 PR 中，由作者自行合并且未获得任何其他 MariaDB 团队成员评审的数量。
- 作者自行关闭（无评审）的 PRs：该周打开的 PR 中，未获得任何有意义响应并由作者自行关闭的数量。
我将从 2023年6月的报告继续，但快照 CSV 文件包含截至目前的整年数据。我还将拉取请求计数和响应数据拆分为单独的表格，否则列数会过多。
| 截止周 | 新 PRs | 草稿 PRs | 已关闭 PRs | 已合并 PRs | 总 PRs | 仍开放 PRs |
|---|---|---|---|---|---|---|
| 2023-06-18 | 7 | 1 | 3 | 0 | 2661 | 155 |
| 2023-06-25 | 4 | 0 | 0 | 4 | 2665 | 155 |
| 2023-07-02 | 5 | 0 | 4 | 0 | 2670 | 156 |
| 2023-07-09 | 6 | 0 | 1 | 5 | 2676 | 156 |
| 2023-07-16 | 8 | 0 | 1 | 8 | 2684 | 155 |
| 2023-07-23 | 14 | 0 | 4 | 6 | 2698 | 159 |
| 2023-07-30 | 7 | 0 | 8 | 7 | 2705 | 151 |
| 2023-08-06 | 3 | 0 | 2 | 3 | 2708 | 149 |
| 2023-08-13 | 7 | 0 | 4 | 1 | 2715 | 151 |
| 2023-08-20 | 5 | 0 | 3 | 2 | 2720 | 151 |
| 2023-08-27 | 7 | 0 | 1 | 0 | 2727 | 157 |
| 2023-09-03 | 5 | 0 | 1 | 4 | 2732 | 157 |
| 2023-09-10 | 10 | 1 | 1 | 4 | 2743 | 162 |
| 2023-09-17 | 7 | 1 | 13 | 5 | 2750 | 151 |
| 2023-09-24 | 9 | 0 | 2 | 3 | 2759 | 155 |
| 2023-10-01 | 5 | 0 | 6 | 1 | 2764 | 153 |
| 截止周 | 首次响应天数 | 已响应的新 PRs | 未响应的新 PRs | 作者自行合并（无评审）的 PRs | 作者自行关闭（无评审）的 PRs |
|---|---|---|---|---|---|
| 2023-06-18 | 1.5 | 4 | 2 | 0 | 0 |
| 2023-06-25 | 12.8 | 4 | 0 | 0 | 0 |
| 2023-07-02 | 0.3 | 3 | 1 | 1 | 0 |
| 2023-07-09 | 17.4 | 5 | 1 | 0 | 0 |
| 2023-07-16 | 19.2 | 5 | 2 | 1 | 0 |
| 2023-07-23 | 26.8 | 5 | 5 | 2 | 2 |
| 2023-07-30 | 4.3 | 3 | 3 | 1 | 0 |
| 2023-08-06 | 9.7 | 3 | 0 | 0 | 0 |
| 2023-08-13 | 11.6 | 5 | 1 | 0 | 1 |
| 2023-08-20 | 11.5 | 4 | 1 | 0 | 0 |
| 2023-08-27 | 11.3 | 7 | 0 | 0 | 0 |
| 2023-09-03 | 0.0 | 4 | 0 | 1 | 0 |
| 2023-09-10 | 1.5 | 4 | 3 | 1 | 1 |
| 2023-09-17 | 0.0 | 2 | 4 | 0 | 0 |
| 2023-09-24 | 2.6 | 5 | 3 | 0 | 1 |
| 2023-10-01 | 1.0 | 1 | 4 | 0 | 0 |
第一个表格，我过去每次报告都会展示它，表明我们需要改进一些地方。第二个表格则为其增加了全新的维度。七月底，我开始努力推动最旧的拉取请求，以便它们能有所结果。这带来了关闭和合并数量的显著增长，但仍需要做更多工作。
至于响应数据，这里有一些有趣的信息。最大的危险信号是“作者自行合并（无评审）的 PRs”，这指的是作者在没有记录评审的情况下自行合并了代码。评审可能发生在 GitHub 之外，但那里没有记录。需要建立流程来避免这种情况发生。
上次更新报告
指标报告代码库中新增的另一项内容是需要关注的拉取请求报告。这是一个名为 report.py 的工具，下面是一个示例输出，显示了自上次有任何活动以来时间最长的五个拉取请求。这将是我优先处理以使其重新动起来的重点。
下次
如果您希望看到任何新增内容，请告知我们。否则，我将在十二月带着更多指标回来！