基本信息¶

• 下载！
• 关于
• 许可证
• 常见问题解答
• 安全报告

源代码仓库¶

• 一般信息
• 主干
• 2.4

文档¶

• 2.4 版本
• 主干 (开发)
• Wiki

参与进来¶

• 邮件列表
• 错误报告
• 开发者信息
• 用户支持

子项目¶

• 文档
• 测试
• 洪流
• libapreq
• 模块
• mod_fcgid
• mod_ftp

相关项目¶

• Apache Traffic Server
• Apache Traffic Control
• Tomcat
• APR
• mod_perl

其他¶

• 贡献者
• 感谢！
• 赞助

如何为 Apache 贡献补丁¶

第三方补丁对于 Apache 的成功至关重要 - “核心”开发人员无法访问所有平台，而且我们当然不会以所有可能的方式使用 Apache。为此，我们努力使贡献代码变得尽可能容易。但是，我们确实对贡献者有一些期望，以及一个流程来管理所有这一切，仅仅是为了帮助我们管理可能收到的大量贡献。本页描述了该流程。

代码风格¶

我们在代码中使用了一个相当固定的代码格式；这是我们在经过大量辩论后得出的格式。该格式在我们的官方 风格指南 中有描述。虽然项目中有一些代码不遵循风格指南，但通常可以假设，如果您的代码格式与文件中的其他代码不同，那么您的代码就是错误的。

我们对代码质量也有非常高的期望；对我们来说，这意味着避免过度使用静态缓冲区，使用内存池机制（确保正确清理），以及编写线程安全的代码。我们还期望应用一到两级的优化 - 位掩码对此更快吗？strchr() 比 index() 快吗？等等。当然，如果我们有一份真正描述所有这些内容的文档就好了，但我们还没有。

文档¶

对于某些补丁，Apache 文档需要更新，最常见的是增强功能。您可能希望在更新文档之前查看您的补丁是否被认为是普遍可接受的。文档的补丁与任何代码更改一起以相同的补丁格式提交。

请注意，对于 Apache 2.0 及更高版本，大多数文档都是从 XML 生成的。您需要对 XML 版本进行更改。有关更多信息，请参见 https://httpd.apache.org/docs-project/docsformat.html。

选择 Apache 代码的比较级别¶

目前，有两个活跃的 Apache httpd 源代码树

1. Apache httpd 2.4.x（当前版本，GA）

2. Apache httpd 2.5.x（开发/测试版）

补丁应该针对最后一个公开版本创建，或者如果可行，针对相关源代码树中 subversion 中的最新代码创建。针对旧版本创建的补丁可能不适用于当前的源代码。

从 subversion 获取源代码树的说明位于 Apache 开发说明

补丁格式¶

我们更喜欢以统一 diff 格式提交补丁

diff -u file-old.c file.c

但这并非所有平台都可用。如果您的平台不支持统一 diff，请改用上下文 diff

diff -C3 file-old.c file.c

其中 file.c 是受影响的文件。我们应该能够将补丁直接输入“patch”程序，并让它更新文件或文件集。-C3 非常重要 - 行号在某些代码文件中每天都会发生变化，因此拥有上下文对于了解所有内容的真正位置至关重要。

如果修改了多个文件，以下设置可以简化原始文件和修改文件的管理

1. cd /sources

2. tar xvzf httpd-2.4.x.tar.gz

3. cp -ax httpd-2.4.x httpd-2.4.x.new

4. 编辑 httpd-2.4.x.new 中的文件并构建/测试

5. cd /sources

6. diff -ru httpd-2.4.x httpd-2.4.x.new > my_unified_diff.patch

如果您的源代码树是从 subversion 中检出的

    svn diff

将以正确的格式创建补丁。

提交您的补丁¶

传统上，补丁已在开发者邮件列表以及通过错误数据库提交。不幸的是，这使得难以轻松跟踪补丁。而且，如果没有能够轻松跟踪它们，其中太多补丁被忽略了。

补丁现在必须通过错误数据库提交，地址为 http://bz.apache.org/bugzilla/。如果您还没有，您需要在那里创建一个 Bugzilla 帐户。首先输入一个新的错误报告来提交补丁。如果补丁是针对 srclib/apr 或 srclib/apr-util 中的文件，请确保指定 APR 作为产品。以下信息非常有用，如果可用

1. 解释如何重现问题以及如何测试补丁

创建错误报告后，再次编辑它，并指定 **PatchAvailable** 作为关键字，然后将您的补丁添加为新的附件。

如果您希望在开发者的邮件列表中讨论补丁，请在主题行前加上“[PATCH <PR-number>]”来引用您的补丁提交。

请注意，核心开发人员倾向于对进入 Apache 核心的内容非常保守。Apache 具有非常灵活的 API，任何高级功能都可能被推送到第三方模块。可移植性修复是最重要的；协议正确性对我们来说也很关键；而且我们确信代码中存在比我们能用棍子敲打的更多愚蠢的错误。这些将优先考虑；新功能可能不会。

如果我的补丁被忽略怎么办？¶

由于 Apache 只有少数志愿者开发人员，而且这些开发人员通常非常忙碌，因此您的补丁可能不会收到任何立即反馈。开发人员必须优先考虑他们的时间，首先处理严重的错误以及他们感兴趣和了解的代码部分。以下是一些关于您可以做些什么来鼓励对您的补丁采取行动的建议

1. 坚持但礼貌。发布到开发者列表，指出您的补丁以及您认为它重要的原因。您可以每周大约这样做一次，并继续这样做，直到您得到回复。只要确保礼貌地对待，因为开发人员不太可能回复粗鲁的消息。

2. 鼓励其他 Apache 用户审查和测试您的补丁，然后在错误报告中添加一个包含详细信息的注释。如果开发人员看到补丁已被广泛测试，他们更有可能审查和提交补丁。

3. 确保您的补丁易于阅读和应用。遵循上述部分中的所有风格建议，并包含任何必要的文档更改。

4. 查看错误数据库以查找类似的错误。如果有重复项，请将它们关闭为初始报告的重复项（这将交叉引用这两个错误）。如果特定的错误报告包含有用的独特详细信息，请在关闭记录良好的重复项时添加额外的注释。如果有一个报告并不完全相同，但可能受益于您的补丁，请将其标记为“依赖于”包含您的补丁的错误报告。最后，将原始事件标记为“依赖于”包含补丁的错误报告。

5. 通过处理您可以礼貌且正确解决的其他错误报告来获得“奖励积分”。虽然这项工作很糟糕 - 就像游行队伍后面的便便队一样 - 但它让主要提交者有时间解决真正的错误及其解决方案，而不是清理粪便。