我应该在向比特币核心回购（Bitcoin Core repo）开放的拉取请求（pull request，PR）的描述中包括什么，以帮助审阅者快速高效地审阅和测试PR？
比特币核心开发
比特币核心评论
分享
改进这个问题
跟随
昨天编辑的
昨天问
迈克尔·福克森
597277银牌2222铜牌
添加评论
1个答案
1
目前在contribution.md中有一些（有限的）指导。
拉请求的标题应以拉请求影响的组件或区域作为前缀
e、 g.共识：为BIP-XXXX OP\U CHECKAWESOMESIG添加新的操作码
pull请求的主体应该包含对补丁做了什么的充分描述，更重要的是，为什么要这样做，以及理由和推理。您应该包括对任何讨论的引用（例如，其他问题或邮件列表讨论）。
很难准确地解释PR描述中应该包含什么，因为这在很大程度上取决于它是什么类型的pull请求(新请求的描述不应该包含任何@提及。）一个小文档PR只需要一两句话来解释更改和进行更改的理由。在另一个极端，一个共识的改变将需要一个长的，详细的描述，解释历史背景，链接到以前的讨论（例如BIPs，邮件列表），并说服评论者，社区对这个改变有共识。
然而，公关作者应该设法使公关审查尽可能容易。理想情况下，评审人员应该能够从PR描述中了解PR试图做什么以及为什么，而不必探索PR链以获得所需的上下文。另外，关于审阅者应该注意什么的指针（特别是如果有特定的安全考虑）或者关于审阅者如何测试PR的指导也可能被证明是有用的。如果它很容易被审查，那么它更有可能被审查。
fanquake在这个公关评论中提供了一些额外的指导：
PR描述（和commit消息）可能包括：正在更改什么，为什么它等同于以前的检查？什么时候变的？e、 qt5.12并不是我们构建Qt的唯一版本，我们支持的最低版本仍然是5.9.x。如果所构建的Qt版本与此更改无关，为什么会这样？链接到相关的上游变更（如适用）。
您如何验证/评审员应如何验证这是一个无操作？e、 g.“如果这是对配置检查的更改，那么在更改之前和之后生成的二进制文件应该是相同的。你可以用build for compare.py来证明这一点。”
添加更多的信息不仅意味着更多的贡献者可以，或者将更有可能进行审查，而且任何与安全相关的更改都应该比“依赖项头中发生的某些更改”更好地进行总结。
公关作者还应该考虑使公关容易测试新的/经验不足的审查，尤其是如果它不是一个复杂的公关，需要大量的上下文理解。
一个很好的例子，公关的描述，为经验较少的评论家是这一个从乔恩阿塔克。它精确地列出了审阅者需要做什么来验证功能是否如所描述的那样工作，包括审阅者可以运行的确切命令。
欢迎测试和审核！如何测试：
要运行full-live仪表板（在Linux上）：$`watch–interval 1
要运行完整的仪表板：$./src/bitcoin cli-netinfo 4
要查看帮助：$./src/bitcoin cli-netinfo help
查看帮助摘要：$./src/bitcoin cli-help | grep-a4netinfo
这里有Jon Atack关于向比特币核心提交拉取请求的额外指导。
分享
改进这个答案
跟随
