前排提示，本文全文长 1.6w 字，由十个故事组成。出于微信公众号的展示特点，我将其切成若干个部分分开推送。如果想要单页读完全部内容，请点击阅读原文跳转网页，网页展示有目录，可以快速导航。
go-redis
最后一个正面的上游优先的故事，我想讲一下 Apache Kvrocks (Incubating)[1] 和 go-redis[2] 相互的合作。
上游优先，进一步分析，并不只是 fork 到 upstream 的方向，也不总是从依赖的软件到被依赖的软件的方向；上游优先换个角度看，可以说是一个包含软件 A 和 B 的整体解决方案，自己作为软件 A 的开发者，在发现解决方案的部分问题更适合在软件 B 解决的时候，首先选择在软件 B 的范畴内解决，而不是在自己的“领地”里费尽心思的绕过。
Kvrocks 是一个兼容 Redis 协议的分布式 NoSQL 系统，go-redis 是实现 Redis 协议的 Golang 客户端。我在选型替换 Kvrocks 社群里无人熟悉的 TCL 测试的时候，最终选择基于 go-redis 来写集成测试。
•refactor: write integration tests in Golang[3]
当然，这里选型的主要是 Golang 语言 Kvrocks 的开发者都比较熟悉，而且写起测试这样非关键路径的代码简单粗暴，而 go-redis 是 Redis Golang 客户端几乎最好的实现。不过，有一件小事让我对选用这个软件更有信心。
•Correct Kvrocks spells and new repo location[4]
偶然之中，我发现 go-redis 其实很早就在 README 里提及了自己支持访问 Kvrocks 服务端。由于 Kvrocks 今年四月份捐赠到 Apache 孵化器，我顺手改正了上游 README 的表述和链接。go-redis 维护者 @vmihailenco 不仅很快合并了修改，还对 Kvrocks 捐赠这件事表达了祝贺。
当时我就觉得，我很愿意和这个人合作。因此我在下面留言说明我将要做的替换工作，而他也很热心地表示如果出现什么问题，欢迎和他反馈。
一开始的迁移很顺利，我就夸赞了 go-redis 真不错。随后一些复杂测试用例的迁移过程里，我逐渐发现了 go-redis 的一些问题，其中有部分是 Kvrocks 的实现和 Redis 不一致需要改进。每次遇到问题，我基本都会 @vmihailenco 告知他我们用例测出来的问题，并且向他寻求 go-redis 使用上的帮助。
迁移过程中，我还发现 go-redis 没有实现部分 Redis 命令的封装接口。跟 @vmihailenco 确认这只是工程工作量太大没有全部实现，其实是需要的之后，我随手就提交了一个补丁帮助 go-redis 实现了相关接口。
•feat: support eval_ro and evalsha_ro[5]
因为 Kvrocks 可以使用底层接口完成测试，而且我知道上游会在 v9 版本包括这个改动，也就是说发布是确定的，而我不着急使用，所以这一次我没有用定型文催促上游明确发布时间。
这种上游优先是相互的。显然我为 go-redis 提交了一些代码，并且向上游反馈了不少使用案例，不过 @vmihailenco 也为 Kvrocks 和 Redis 的兼容性提供了非常有价值的输入，并且帮助 review 替换过程中遇到的问题。
应该说，这是开源社群当中的一种常态。大家不是完全基于契约和合同行动，不在契约之内的事情就想方设法避开，而是基于善良和合作的假设，帮助别人，并时不时得到别人的帮助。上下游的合作是相互的，作为积极反馈上游社群的下游，往往也更能得到上游社群反过来的帮助。
References
[1] Apache Kvrocks (Incubating): https://kvrocks.apache.org/[2] go-redis: https://github.com/go-redis/redis[3] refactor: write integration tests in Golang: https://github.com/apache/incubator-kvrocks/pull/806[4] Correct Kvrocks spells and new repo location: https://github.com/go-redis/redis/pull/2202[5] feat: support eval_ro and evalsha_ro: https://github.com/go-redis/redis/pull/2221