Apache 投票规则和指南
本文档定义了 Apache 小组成员在对 Apache HTTP Server 的补丁、文档或其他待执行项目进行投票时应遵循的规则和指南。
这里的目标是避免对更改进行不必要的冲突，并继续以及时的方式生成高质量的系统。并非所有冲突都能避免，但至少我们可以就解决冲突的程序达成一致。
下面使用了一些缩写...
问题和待执行项目 投票邮件列表中的任何人都可以对任何问题进行投票。但是，投票行为会带来某些义务——投票成员不仅是在表达他们的意见，他们还同意帮助完成 Apache 项目的工作。
每个投票都可以以三种方式进行
所有投票都必须发送到邮件列表。
正式补丁投票如上所述，对源代码的更改需要同行评审并在许多平台上进行充分测试。正式的补丁投票规则旨在确保即使我们都急于看到问题得到解决，也能做到这一点。但是，另请参阅有关 懒惰投票 模式的部分。
补丁投票流程中有四个不同的角色，每个角色都可能由多个小组成员共享：补丁提供者、投票协调员、投票者和版本构建者。
补丁提供者包括任何提出待执行项目的人员。除非不可行，否则源代码更改必须以补丁命令的输入形式提出。可行性由每个投票者和版本构建者定义，他们可能会否决待执行项目，如果该操作需要超出他们预期执行的工作量。
待执行项目（通常是补丁）通过 FTP 上传到 hyperreal（apache.org），可以直接上传到 CURRENT 的补丁目录（/httpd/patches/for_Apache_C_VERSION/）中，或者上传到传入的 FTP 目录中，以便稍后转移到补丁目录中。
每个文件名至少应该暗示操作目标，并包含对以下内容的引用
不包含补丁的文件名的语法为
ID.description例如，
01.Modula3_rewrite如果待执行项目不是（尚未）补丁形式。
包含补丁的文件名的语法为
IDp.description.C_VERSION.patch例如，
01.ScriptAliasKaboom.0.8.11.patch
01a.ScriptAliasKaboom.0.8.11.patch
01b.ScriptAliasKaboom.0.8.11.patch
ID 号应从 01 开始，并为上传的每个新待执行项目递增。
待执行项目应包含一个标题信息列表（格式类似于电子邮件或 HTTP 标题）
补丁应通过在 CURRENT 源代码和修改后的源代码上使用 diff -u 来创建。例如，
diff -u http_main.c.orig http_main.c
解决待执行项目所需的所有补丁必须在一个补丁文件中连接起来。补丁文件影响的源文件应列在 Affects 标题中。
完成的补丁文件在执行以下命令时不应产生任何错误或提示，
patch -s < patchfile。
如果补丁产生错误或提示，则其他人可能会拒绝它。补丁问题应在发现后立即报告给邮件列表。补丁之间的依赖关系必须在补丁文件标题中使用 Requires 行进行注释。
上传后，对补丁文件内容的更改仅限于标题信息（即，除补丁本身以外的所有内容）。例如，可以更改 Changelog 条目，但不能更改 diff 命令的输出。
如果补丁本身需要更改，则应使用新的补丁字母在 ID 后创建新的补丁文件。任何人都可以上传补丁来解决单个问题，因此可以为同一个问题提供备用补丁。补丁的作者是唯一被允许（或给予许可）删除现有补丁的人。删除补丁意味着删除补丁文件。
每个补丁文件都独立进行投票。新的备用补丁必须获得自己的投票——它们不会自动继承替换它们的补丁的投票。
CURRENT 的补丁可以在投票会议之前或期间的任何时间上传。
只要能找到志愿者来执行以下操作，任何人都可以发起投票会议
自愿执行这些任务的人员会商定一个时间表并在邮件列表中宣布。时间表的重要部分是投票截止日期，它指定了何时统计投票结果以及何时可以构建新版本。除非是 紧急情况，否则初始截止日期应至少在宣布后三天。
如果使用与补丁相同的投票规则，有足够的投票且没有否决，则可以移动投票截止日期。当前截止日期不能进行投票。
小组成员可以随时投票和评论正在考虑的补丁。一个人的最终投票（如果投票发生变化）被认为使之前的投票无效。
投票如下进行；
任何否决都不能被推翻。如果您不同意否决，您应该游说投出否决的人。打算否决补丁的投票者应立即将他们的意见告知小组，以便在投票截止日期之前尽可能地解决问题。
投票协调员在最终投票截止日期过后立即统计投票结果。然后，投票结果将发布到邮件列表中。
为了获得批准，待执行项目文件必须至少获得 3 票赞成票，并且 **没有** 否决票。
投票协调员可以自行决定忽略或接受迟到的 +1 票。迟到的否决票无效：它只能用于试图说服赞成票重新考虑。如果赞成票更改为否决票，则该否决票即使是迟到的也是有效的。
在投票协调员将结果提供给版本构建者后，通过将已批准的补丁应用于 CURRENT 来创建 NEXT，进行其他已批准的（非补丁）待执行项目所要求的更改，将已批准的待执行项目描述添加到更改日志中，并递增版本号。
然后，版本构建者将 NEXT 上传到 hyperreal 并将其放置在预发布目录（/httpd/dist）中，以压缩和 gzip 压缩的 tar 文件形式命名新版本号。然后，将在私人邮件列表中宣布新版本的可用性。
版本发布公告后，构建者所犯的错误可以无需投票直接修正，但必须向小组公布。
除非在投票环节开始时另有说明，否则**NEXT**默认将发布到公众。如果有人反对公开发布，则需要进行多数决投票来决定是否公开发布。与其他投票不同，少数意见无法阻止公开发布。
如果**NEXT**将公开发布，邮件列表中的每个人都应尽力下载并试用。**NEXT**在创建并向小组公布后 24 小时内不得公开发布。
如果用于创建**NEXT**的补丁之一被发现会导致比其修复的问题更严重的问题，则应向小组报告此问题，并将任何公开发布推迟到获得关于如何解决此问题的多数决意见为止。
在紧急补丁/投票环节以修复安全问题的情况下，小组可能需要绕过上述正常操作流程，以便在公开宣布问题之前进行修复。任何小组成员都可以在邮件列表中宣布紧急情况，并在被告知严重问题时立即这样做。任何小组成员都可以否决紧急情况，以迫使其通过正常流程。
用于解决紧急问题的补丁可以在补丁创建并由其作者测试后立即从 Apache 主页直接链接。但是，如果原始补丁被否决，则必须删除或更改此链接。
在补丁创建后 24 小时或获得三个 +1 投票后，无论哪个先发生，都可以向公众宣布紧急补丁的可用性。
在某些情况下，例如在开发周期的早期，可能需要在所谓的“懒人”投票模式下运行。这与正式投票流程基本相同，只是“沉默即同意”——如果 48 小时内没有否决，即使没有正式收集，也会假设有足够的“赞成”票。
正式投票环境和懒人投票环境可以共存；某些主题可能需要正式投票，而另一些主题则不需要。应运用常识，潜在的极具争议性的补丁不应在懒人规则下提交。
当补丁提交者希望利用懒人投票模式时，必须在补丁提交中明确说明。