跳到主要内容

贡献

IvorySQL由一个核心开发团队维护,该团队拥有对GitHub上的IvorySQL主存储库的提交权限。同时,我们非常渴望从更广泛的IvorySQL社区中的成员那里获得贡献。如果您希望看到您的代码或文档更改被添加到IvorySQL并出现在将来的版本中,本节的内容介绍是您需要知道的。

开始

IvorySQL是在GitHub上开发的,任何希望对其作出贡献的人都必须拥有GitHub帐户,并熟悉Git工具和工作流。还建议您遵循开发人员的邮件列表,因为一些贡献可能会在那里产生更详细的讨论。

如果您有GitHub帐户,fork这个存储库,这样您就可以拥有您的私人副本来开始hacking,并将其用作拉取请求的来源。

IvorySQL贡献的许可

如果您提交的贡献是原创作品,那么您可以假设IvorySQL将作为整个IvorySQL版本的一部分发布给下游用户,该版本将遵循Apache许可证2.0版本。

如果您提交的内容不是原创作品,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布。请注意需要满足如下条件:

1、需要给代码的用户一份Apache许可证。

2、如果您修改了代码,需要在被修改的文件中说明。

3、在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。

4、如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache许可证。您可以在Notice中增加自己的许可,但不可以表现为对Apache许可证构成更改。

最后,请记住,从非原始的工作中删除许可标头从来都不是一个好主意。即使您使用的文件部分最初在顶部有许可标头,您也应该保留它。与往常一样,如果您不太确定您的贡献所涉及的许可问题,请随时在开发人员邮件列表中联系我们。

编码指南

您获得反馈和看到代码合并到项目中的机会在很大程度上取决于更改的粒度。如果您的想法发生了更大的变化,我们强烈建议您在花大量时间编写代码之前,先加入开发人员的邮件列表,并与我们分享您的建议。即使您的建议得到社区的验证,我们仍然建议您将实际工作作为一系列小型的、独立的提交来完成。这使得评审员的工作更加容易,并提高了反馈的及时性。

当谈到IvorySQL的C和C++部分时,我们尝试遵循PostgreSQL编码约定。除此之外:

对于C和Perl代码,如果需要,请运行pgindent。我们建议在查看更改时使用git diff--color,这样您提交的代码中就不会出现任何虚假的空白问题。

所有贡献给IvorySQL的新功能都应该由与其一起贡献的回归测试覆盖。如果您不确定如何测试或记录您的工作,请在ivorysql-hackers邮件列表中提出问题,社区的开发人员将尽力帮助您。

至少,您应该始终运行make installcheck world,以确保您没有破坏任何东西。

适用于上游PostgreSQL的更改

如果您正在进行的更改涉及PostgreSQL和IvorySQL之间的通用功能,则可能会要求您将其转发到PostgreSQL。这不仅是为了我们不断减少两个项目之间的差异,而且是为了让与PostgreSQL相关的任何变化都能从对上游PostgreSQL社区更广泛的审查中受益。一般来说,将这两个代码库都放在手边是个好主意,这样您就可以确定您的更改是否需要前移。

补丁提交

一旦您准备好与IvorySQL核心团队和IvorySQL社区的其他成员共享您的工作,您应该将所有提交推送到从官方IvorySQL派生的分支的您自己的存储库中,并向我们发送请求。

补丁审查

假定提交的拉取请求通过验证检查,可供同行审查。同行审查是确保对IvorySQL的贡献具有高质量并与路线图和社区期望保持一致的过程。我们鼓励IvorySQL社区的每个成员审查请求并提供反馈。由于您不必成为核心团队成员就可以做到这一点,因此我们建议您向有兴趣成为IvorySQL长期贡献者的任何人提供一系列拉动式评论。

同行评审的一个结果可能是达成共识,即您需要以某些方式修改pull请求。GitHub允许您将其他提交推送到从中发送请求的分支中。这些额外的提交将对所有审阅者可见。

当同行评议收到参与者至少+1张+1和no-1张的选票时,同行评议会趋于一致。在这一点上,您应该期望核心团队成员之一将您的更改引入到项目中。

在补丁审查期间的任何时候,您都可能会因审查人员和核心团队成员的工作效率而遇到延迟。请耐心点,也不要气馁。如果您在几天内没有收到预期的反馈,请添加一条评论,要求更新pull请求本身,或者向邮件列表发送一封电子邮件。

直接提交到存储库

有时,您会看到核心团队成员直接提交到存储库,而无需执行pull请求工作流。这仅适用于小的更改,我们使用的经验法则是:如果更改涉及任何可能导致测试失败的功能,那么它必须通过pull请求工作流。另一方面,如果更改发生在代码库的非功能部分(例如在注释块中修复打字错误),则核心团队成员可以决定直接提交到存储库。