上游优先的故事

[tisonkun]

https://town.korandoru.io/blog/upstream-first-stories

[dzzxjl]

Java 开发者对于应用代码和库函数是比较熟悉的，而一旦涉及到构建系统比如 Maven 或 Gradle 等，则会天然地产生一种陌生的刻板印象。

很认同tison的这段话~概读了通篇文章，收货很大

[tisonkun]

谢谢。其实构建系统只是另一种软件而已。当然，我直到现在也搞不懂游戏和各类 GUI 的编程技巧。但是做系统软件编程，折腾构建是再正常不过的事情了。编译、链接和打包，在系统软件被广泛使用和依赖复杂的前提下，总是会遇到各种各样的问题。我也是从一开始看到 Maven 配置就犯怵，到现在能 debug 和开发常见的构建系统插件和核心流程。

[xxchan]

贡献一个上游优先的还未成功的小故事：

起因是在 engula 里看到 format Cargo.toml 的需求 huachaohuang/ekv#181 ，用 taplo 作为 workaround 部分实现了之后，我发现上游 rustfmt 已经有一个一年多的这个问题的讨论 rust-lang/rustfmt#4091 。里面讨论了许多包括 taplo 在内的 workaround，以至于 maintainer 出来声明说这个功能是在 rustfmt 的 scope 内的，我们要自己支持，不要再提 workaround 了。只不过迟迟没有人愿意出来实现。

几个月后我突然有闲心，就花了一个周末实现了 rust-lang/rustfmt#5240 。经过一番 review 以后，maintainer 表示实现的挺好，但是因为种种小原因没合进去。之后我精力有限没有继续推进完善，maintainer 也是带宽非常有限，最后打上了 low priority 和 pending review 的 tag，就大半年又过去了。 🤣

[xxchan]

这个 case 主要是上游 maintainer 带宽很有限 + 优先度不高，而我只做了核心实现，没有完全集成好到工具链里（rustfmt 支持了，cargo fmt 还不支持），所以就不急着合并，然后也没有人继续推进。如果我有空再搞两下弄到 cargo fmt 里，加个 feature 开关，估计就能合进去让大伙用着了。🤪

[tisonkun]

我也有点印象 rustfmt 的 maintainer 确实很少，rust 其他团队的人也很少看这个项目。应该说大部分个人项目都有这个问题，尤其是 maintainer 对项目要做成什么样子想得不太清楚的。我记得 rustfmt 现在主要的 maintainer 不是作者，他的心态可能就是 maintain mode 算逑..