Committer指南

发布于 2021-09-30 01:42:49 字数 9609 浏览 1136 评论 0 收藏 0

Committer新人指南

订阅公共邮件列表

请订阅{dev,commits}@doris.apache.org邮件列表，通过发送邮件到{dev,commits}-subscribe@doris.apache.org完成订阅。 commits邮件非常重要，因为所有的GitHub Issue，PR提交都会发往这个邮件列表。

订阅private邮件列表

订阅private@doris.apache.org通过发送邮件到private-subscribe@doris.apache.org完成订阅。这个订阅操作需要邮件列表的moderator进行审核才能订阅成功。如果你是PPMC的话, 可以通过通过邮件列表订阅帮手直接完成订阅。

关联你的 ASF 账号与 Github 账号

我们用GitHub来管理我们的Issue以及用户贡献。所以你需要把你的ASF账号与GitHub账号进行关联来获得Doris仓库的写入权限。通过在Gitbox完成操作后，你就可以对GitHub仓库中的Issue，PR进行管理。

Code Review指南

始终保持一个较高的标准来进行review，这样才能更好地保证整个产品的质量。
对于用户接口类的、整体架构方面的修改，需要在社区进行充分地讨论，可以在邮件组发起，也可以在issue上发起。用户接口的改变包括支持新的SQL函数，支持新的HTTP接口，支持新的功能等。这样能够保证产品的一致性。
测试覆盖。新增的逻辑需要有对应的测试来覆盖。对于已有老代码，不好增加的可以酌情考虑。
文档。新增加的功能必须要有文档来说明，否则这样的代码不允许合入。必须要有英文文档，最好有中文文档。
代码的可读性。如果review的同学对于代码逻辑不是很清晰，那么可以要求contributor去解释这段逻辑，并且需要在代码里写充分的注释来解释逻辑。
尽量在评论的结尾给出明确的结论。是同意，还是要change request。如果是小问题，可以只留评论。
如果你已经看过了代码，觉得没有问题，但是觉得需要其他同学来确认下，可以留下+1 Comment。
互相尊重，互相学习。在评论的时候保持礼貌的口吻，提建议尽量给出建议的理由。

Pull Request指南

一个PR合入需要三种角色的参与。Contributor：PR的提交者；Reviewer：对PR进行代码级评论的人；Moderator：PR合入的协调者。 Moderator主要负责给PR设定相关标签，推动相关reviewer进行评论，推动作者对PR进行修改，合入PR等工作。在一个具体的PR中，一个人可能充当不同的角色，比如一个Committer自己提交的PR，既是Contributor，又是这个PR的Moderator。
Committer可以把一个PR分配给自己作为整个PR的moderator，负责后续PR的推动工作。分配给自己之后，其他的Committer就知道这个PR有相关人负责了。
鼓励Committer作为自己PR的Moderator。
Reviewer需要进行代码级的review，可以参考Code Review Guideline。
Reviewer一旦评论了某个PR之后，需要持续跟进这个PR的后续改动，不鼓励评论了之后就不再管Contributor的后续回复了。
一个PR至少要获得一个非作者外的Committer +1才能进行被合入。
PR获得第一个+1后，至少要等一个工作日后才能进行合入。主要目的是等待社区其他同学来进行review。
对于接口类、整体架构方面的修改，至少要获得3个+1才能进行合入。
需要回归测试全部通过才能被合入。
Moderator需要在确定所有的评论都被回复之后才能进行代码合入。
代码合入选择“squash and merge”方式进行合入。
对于一个修改不同的reviewer有争议时，可以尝试讨论解决。如果讨论没有办法解决，可以在private@doris中发邮件投票解决，采取少数服从多数的原则。