维护者指南
目录
维护者指南¶
此页面介绍了 Dask 维护者的最佳实践。
感谢您帮助将 Dask 打造成一个有用的库，并营造了一个热情的社区。
合并拉取请求¶
拉取请求应进行评审¶
来自非维护者的拉取请求应在合并前由至少一名维护者评审和批准。
理想情况下，维护者的拉取请求也应在合并前进行评审。但是，由于评审者的时间有限，如果拉取请求的内容被视为无争议（例如，修正拼写错误），维护者有时会自行合并自己的拉取请求。如果维护者有一个重要的拉取请求但未收到评审，他们应提醒至少一个可能对拟议更改感兴趣的团队或个人维护者。如果一段时间后没有回应，并且维护者对拟议的更改有信心，他们应发布一条最终评论，内容大致为“如果在 48 小时内没有进一步回应，则合并”，然后在指定时间段内没有留下进一步评论的情况下自行合并。请至少留出 48 小时，以便其他时区的维护者回应。
维护者不应合并他们未来不便支持的拉取请求。
CI 应通过¶
在合并拉取请求之前，维护者应尽一切努力确保 CI 通过。这通常需要查看失败运行的日志以了解问题所在，并通知拉取请求的作者。理想情况下，如果 CI 失败，不应合并任何拉取请求，因为主分支 (main) 中损坏的 CI 很容易掩盖其他 PR 的问题，而且持续损坏的 CI 会让维护者感到沮丧。
然而，在实践中，偶尔会出现不稳定的测试、损坏的上游依赖以及其他明显与当前 PR 无关的失败。如果出现这种情况，维护者可能会合并带有失败测试的 PR，但他们应准备好跟进由此类不安全操作导致的任何失败。
压缩合并拉取请求¶
在合并拉取请求时，请使用压缩合并（Squash merging），而不是像 rebase 合并等其他合并策略。为了简化此过程，仓库的 GitHub 设置中已禁用所有非压缩合并策略。
使用清晰的合并提交¶
Dask 致力于拥有一个直接而有意义的 git log。为此，维护者应确保压缩合并的提交标题和（可选的）消息在合并前能有意义地反映拉取请求的内容。例如，合并提交标题“fix typo”应更新为“Fix typo in Array.max docstring”之类的描述。
请注意，在压缩合并拉取请求时，GitHub 默认会将相应拉取请求中的所有单个提交消息串联起来填充到压缩提交消息中。根据拉取请求作者在开发过程中的细心程度，此默认消息可能会非常冗长且描述性不足。例如
* Fix DataFrame.head bug
* Handle merge conflicts
* Oops, fix typo
如果出现这种情况，合并拉取请求的维护者应执行以下任一操作：
编写自己的合并提交消息来描述拉取请求中的更改（如果他们有时间的话）。
将合并提交消息留空（同样，确保提交标题有意义）。