维护者指南
目录
维护者指南¶
本页介绍 Dask 维护者的最佳实践。
感谢您帮助将 Dask 打造成一个实用的库，并促进社区的友好发展。
合并拉取请求¶
拉取请求应进行审查¶
非维护者的拉取请求在合并前应由至少一名维护者审查并批准。
理想情况下，维护者的拉取请求在合并前也应进行审查。然而，由于审查者带宽有限，如果拉取请求的内容被视为无争议（例如，修复拼写错误），维护者有时会自行合并其自己的拉取请求。如果维护者有一个尚未收到审查的大型拉取请求，他们应提醒至少一个可能对提议的更改感兴趣的团队或个人维护者。如果在一段时间后没有回应，并且维护者对其提议的更改充满信心，他们应发表一条最终评论，内容类似于“如无进一步回应，将在 48 小时内合并”，然后如果在指定时间内没有留下进一步评论，则自行合并。请至少预留 48 小时，以便其他时区的维护者作出回应。
任何维护者都不应合并他们将来无法支持的拉取请求。
CI 应通过¶
在合并拉取请求之前，维护者应尽一切努力确保 CI 通过。通常，这需要查看失败运行的日志，了解哪里出了问题，并通知拉取请求作者。理想情况下，如果存在 CI 失败，则不应合并任何拉取请求，因为 main 分支中损坏的 CI 很容易掩盖其他 PR 的问题，并且持续损坏的 CI 会使维护者士气低落。
然而，在实践中，偶尔会出现不稳定的测试、上游依赖项损坏以及明显与当前 PR 无关的故障。如果是这种情况，维护者可以合并带有失败测试的 PR，但他们应准备好跟踪由这种不安全操作导致的任何故障。
合并拉取请求时使用 Squash Merge¶
合并拉取请求时使用 Squash Merge，而不是 Rebase Merge 等其他合并策略。为了简化此过程，仓库的 GitHub 设置中已禁用所有非 Squash Merge 的合并策略。
使用整洁的合并提交¶
Dask 旨在拥有一个直接但有意义的 git log。为了实现这一目标，维护者确保在合并之前， Squash Merge 提交标题和（可选）消息能够有意义地反映拉取请求的内容。例如，将“fix typo”之类的合并提交标题更新为“Fix typo in Array.max docstring”之类的标题。
请注意，当 Squash Merge 拉取请求时，GitHub 默认会通过连接相应拉取请求中的所有单个提交消息来预填充 Squash 提交消息。取决于拉取请求作者在开发过程中的谨慎程度，这个默认消息可能非常冗长且不够描述性。例如：
* Fix DataFrame.head bug
* Handle merge conflicts
* Oops, fix typo
如果是这种情况，合并拉取请求的维护者应采取以下措施之一：
（如果时间和精力允许）撰写自己的合并提交消息，描述拉取请求中的更改。
留空合并提交消息（同样，确保提交标题有意义）。