欢迎来到新一期的 This Week on TiDB 栏目！TiDB 是一个开源的 MySQL 协议兼容的分布式数据库，支持 HTAP 即混合事务和分析处理。
这个栏目是个人向的 TiDB 观察评论，如果你看到了有趣的事情想让这个栏目评论，或者自己做了有意思的事情想分享出来，欢迎私信联系我或者在下方链接的 issue 中提出。如果你有意了解或加入 TiDB 社区，TiDB 社区也非常欢迎贡献者。
国庆假期彻底打乱了生物钟，这期可能会有些混乱。
Support SELECT FOR UPDATE OF TABLES
首先看到的是 TiDB Maintainer @jackysp 提的一个 SQL 语法增强的改动。如果这个改动实装，TiDB 将可以支持 SELECT 语句里细粒度的表加锁设置。这也是 MySQL 支持的语法之一。
值得一提的是，@jackysp 为这个功能撰写了设计文档和对应的 issue 记录。这两点分别受到 TiDB 社区最近在开源协同最佳实践上提出的两个提议的影响。
其之一是 Public Design 即功能增改都需要有公开的设计，可以是上面这个语法改动实现时的设计文档，对于简单三两句能讲清的，也可以在 issue 当中描述清楚。
这样做的目的是在开源社区当中分享软件开发除了代码本身以外极具价值的架构设计和技术原理。
Discuss: Understand the Complexity of Region Merge on TiKV
例如在这个 topic 里，TiKV Contributor @ralph 就想了解 TiKV 在设计数据分片方案的时候，对 Region Merge 这个议题的设计思路和背景。其实 TiKV 在实现过程当中肯定是考虑过相关问题的，但是因为缺乏 Public Design 和公开可见的讨论存档，因此开源社区的参与者并不能自主的了解相关内容。反过来，TiKV 社区的资深贡献者对软件的了解和新人能自主了解的知识基础差距过大，双方协同更加困难。
希望后续在 TiDB 社区做技术设计的时候，能够保留设计思路和背景，打开 People Power 的大门。
上面的 Discuss topic 里也有 TiDB 社区在讨论这个话题的时候，社区成员提出的一些值得参考的例子和对 Public Design 的目标以及 Non Goals 的思考。
Proposal: add issue number to PR title
其之二是 PR 要求对应到 issue 上，即不允许只有 PR 没有 issue 的情况。
实话说，这个提议多少有点形式主义的味道，但是 TiDB 社区的情况有些过于专注在码代码上面了。issue 能够提醒贡献者首先描述清楚自己的问题，关注到要解决的问题上来，讨论清楚这个问题的来由，要不要做，再开始编码工作。
另一方面，issue 也是广泛的非核心开发者所关注的内容。对于用户和下游开发者来说，其实他们首先不会关心这个问题是怎么被解决的，而是想知道有什么问题，解决了没。或者新实现了什么功能，我能怎么用。Pull request 自然也可以包含这些内容，但是它天然有 changeset 要 review 就导致关注点始终在“代码是怎么写的”上面。而 issue 是“问题是什么”以及“不局限于代码的解法”。
Announcing that parser has been merged into tidb
Tracking issue for moving parser back to TiDB
其他开发方面，pingcap/parser 仓库分久必合回到了 pingcap/tidb 仓库里。项目的主导成员 TiDB Committer @xhebox 发布了相应的 announcement 公告。
不过目前还有一个悬而未决的问题是 parser 从 yacc 文件生成的实际 go 文件体积很大，而且一个小的 parser 规则改动可能导致上千行的生成 go 文件的改动。这个问题考虑到 parser 可能被用作依赖库也就是 go get 获取的前提下不是很好解。
如果有熟悉 go 项目管理和发布的同学可以在上面的 tracking issue 里找到对应的讨论回复指点一二。
Proposal: Merge Dumpling repo into TiDB
另一个计划合并到 tidb 的仓库 pingcap/dumpling 的提案也在逐步推进。仓库的合并背后是数量暴增带来的依赖管理灾难，tidb 和各种工具库的循环依赖问题，以及做一个功能起几个 PR 并且要关注合并顺序甚至忽略测试失败等等体验，相信 TiDB 的贡献者应该多少有所体会。
这些工具项目很多是和 tidb 的逻辑紧密绑定的，并且最终也就是 release 一个 binary 到终端用户使用。这和 MySQL 和 PG 等等项目是一致的。
Request for Review: Migrate tests for statistics package
最后，同步一下测试迁移工作的最新进展，目前还剩 8 个 package 待处理。之所以留到最后，也是因为它们是 TiDB 最复杂的逻辑，要迁移不仅仅是机械化的改代码，更要多少了解一点模块的职责和设计，才能顺利的迁移测试框架。
直接点，这些 package 里面都是 TiDB 的核心逻辑，里面不得已而为之的 hack 很有一些，一不小心就会踩到坑。
这几个 package 分别是
-
br/pkg
-
ddl
-
executor
-
expression
-
planner/core
-
server
-
session
-
statistics
这里面 br/pkg 是之前合并的备份恢复工具的内容，测试写得还不错，属于不怎么掉 SAN 的内容。
expression 表达式虽然本身坑很多，主要是数据类型相关的问题，但是测试还是比较有章法的，比较偏体力活。
planner/core 和 statistics 算是一个 SQL engine 里算法味道最浓的模块，测试还算规整。目前有不少 contributor 都在参与，例如此前提过的 @feitian124 就主力迁移了 statistics 的测试，印度老哥带着好兄弟冲 planner/core 模块。
剩下的 4 个就是工程实现极重的 package 了，需要有耐心才能抽丝剥茧处理各种状态改动的纠缠。不过基本每个 package 都已经起了头，还是可以有所参考的。
上面的 topic 是我在 review statistics 模块的时候遇到的困难，也欢迎看到这里的同学一起参与到测试迁移工作的 review 当中来。
Review 其实是最适合入门开源社区的手段，不是只有写代码才是贡献，review 对于项目的质量也有非常关键的作用。Linux 项目曾经诞生过一句名言，叫“given enough eyeballs, all bugs are shallow”，也就是 review 能够让 bug 无所遁形。review 其实还有一个好处，就是你冲上来写一个 PR 尤其是想搞个大 feature，一般社区都会很低优先级的处理这类“贡献”，因为你还没有获得足够的认可，大部分人会认为 review 你的代码是在浪费时间。但是 Review 至少能够得到 PR Author 的关注，这还是很爽的。另外 Review 也是交流编程经验的一种值得提倡的手段，在 comment 和 comment 之间，自己和别人的编程习惯和经验教训就会碰撞出新的火花，真正在开源社区当中实现共同成长。