---

D.2.4发送Octave的补丁¶

如果您想为Octave编写错误修复或改进,这将非常有帮助。当您发送更改时,请遵循这些指南,以避免在研究补丁时给我们带来额外的工作。

如果你不遵循这些准则,你的信息可能仍然有用,但使用它需要额外的工作。在最好的情况下,维护Octave是一项艰巨的工作,除非你尽最大努力提供帮助,否则我们无法跟上。

• 发送一份解释,说明他们解决了什么问题或带来了什么改进。对于bug修复,只需包含bug返回的副本,并解释更改修复bug的原因。
• 对于您认为已经修复的问题,请始终包含适当的错误返回。在拖延之前,我们需要说服自己改变是正确的。即使它是正确的,如果我们没有办法重现问题,我们也可能难以判断。
• 包括所有适当的注释,以帮助未来阅读该来源的人理解为什么需要进行此更改。
• 不要将出于不同原因所做的更改混在一起。发送它们个别地.

  如果您出于不同的原因进行了两次更改,那么我们可能不想同时安装它们。我们可能只想安装一个。

• 使用差异-c让你与众不同。没有上下文的差异对我们来说很难可靠地安装。更重要的是,它们让我们很难研究差异来决定是否要安装它们。统一diffformat比无上下文diff更好,但不如cformat

  如果您有GNU diff,请使用差异-cp,它显示了每次更改所发生的函数的名称。

• 为您的更改编写更改日志条目。

  阅读变更日志文件,看看什么样的信息给普京,并学习我们使用的风格。更改逻辑的目的是向人们展示在这里的可以找到更改的内容。因此,你需要具体说明你改变了哪些函数;在大型函数中,指出函数中进行更改的位置通常很有帮助。

  另一方面,一旦你向人们展示了在这里的可以找到改变,你就不需要解释它的目的。因此,如果你添加了一个新函数,你需要说的是它是新的。如果你觉得这个目的需要解释,它可能会解释——但如果你把它放在代码的注释中,解释会更有用。

  如果您希望您的姓名出现在更改人的标题行中,请将标题行发送给我们。