本文档定义了Apache HTTP Server 项目的指南。它包括关于如何通过投票解决冲突的定义，谁有投票权，以及提出和更改 Apache 产品的程序。
这里的目标是避免对更改进行不必要的冲突，并继续以及时的方式生产高质量的系统。并非所有冲突都可以避免，但至少我们可以就解决冲突的程序达成一致。
负责管理 Apache HTTP Server 项目的志愿者小组。这包括决定 Apache HTTP Server 项目的产品发布内容，维护项目的共享资源，代表项目发言，解决 Apache 产品的许可证争议，提名新的 PMC 成员或提交者，以及制定这些指南。Apache PMC 的成员资格仅限于邀请，并且必须得到活跃的 Apache PMC 成员的一致同意。PMC 成员被认为是通过他们自己的声明或在超过六个月的时间内没有以任何形式为项目做出贡献而变得不活跃的。不活跃的成员可以通过扭转使他们不活跃的任何条件（即，通过扭转他们先前的声明或再次为项目的运作做出贡献）重新变得活跃。成员资格可以通过除相关成员之外的所有活跃 PMC 成员的一致投票撤销。
负责 Apache HTTP Server 项目技术方面的一组志愿者。该小组对相应的源代码仓库具有写访问权限，这些志愿者可以在任何技术讨论中投出具有约束力的投票。提交者的成员资格仅限于邀请，并且必须得到活跃的 Apache PMC 成员的一致同意。提交者被认为是通过他们自己的声明或在超过六个月的时间内没有以任何形式为项目做出贡献而变得不活跃的。不活跃的成员可以通过扭转使他们不活跃的任何条件（即，通过扭转他们先前的声明或再次为项目的运作做出贡献）重新变得活跃。成员资格可以通过所有活跃的 PMC 成员（除相关成员之外，如果他们是 PMC 成员）的一致投票撤销。
所有为 Apache 项目贡献时间、代码、文档或资源的志愿者。一个持续为项目做出持续、受欢迎的贡献超过六个月的开发者通常会被邀请成为提交者，尽管此类邀请的确切时间取决于许多因素。
Apache 开发者的主要邮件列表，用于讨论与项目相关的议题和更改（dev@httpd.apache.org）。列表订阅是开放的，但只有订阅者才能直接发布到列表中。
Apache PMC 的私人邮件列表，用于讨论不适合公开讨论的议题，例如法律、个人或安全问题，在发布修复程序之前。列表订阅仅对 Apache httpd 的项目管理委员会开放（实际上：强制性）。
所有 Apache 产品都使用Subversion on维护在共享信息库中。只有部分 Apache 开发者对这些仓库具有写访问权限；每个人都有读访问权限。
Apache 项目的每个活跃源代码仓库都包含一个名为“STATUS”的文件，用于跟踪该仓库内工作的议程和计划。STATUS 文件包括有关发布计划的信息，自上次发布以来提交的代码更改摘要，正在讨论的拟议更改列表，有关个人开发者正在处理或希望讨论的项目的简要说明，以及任何其他可能有助于小组跟踪进度的信息。活跃的 STATUS 文件每周都会自动发布到邮件列表中。
项目将遇到许多问题，每个问题都会导致零个或多个拟议的行动项目。问题应在识别后立即在邮件列表中提出。行动项目**必须**在邮件列表中提出并添加到相关的 STATUS 文件中。所有行动项目都可以进行投票，但并非所有行动项目都需要正式投票。
任何 Apache 开发者都可以对任何问题或行动项目进行投票。但是，唯一具有约束力的投票是 Apache HTTP Server 的活跃成员投出的投票；如果投票是关于对源代码或文档的更改，则正在更改内容的主要作者也可以对该问题投出具有约束力的投票。所有其他投票均不具有约束力。鼓励所有开发者参与决策，但决策本身是由那些长期为项目做出贡献的人做出的。换句话说，Apache httpd 项目是一个最低门槛的精英制度。
投票行为承担着一定的义务——投票成员不仅在表达自己的意见，他们还同意帮助完成 Apache 项目的工作。由于我们都是志愿者，成员经常会为了处理他们的“真正工作”或将更多时间投入其他项目而变得不活跃一段时间。因此，整个小组成员不太可能对每个问题都进行投票。为了解决这个问题，所有投票决定都基于最低人数。
每次投票都可以采用三种方式之一
+1：是，同意，或应执行该操作。在某些问题上，只有当投票者在其自己的系统上测试了该操作时，此投票才具有约束力。
±0：弃权，没有意见，或者我很乐意让其他小组成员决定这个问题。如果太多人弃权，弃权可能会产生不利影响。
-1：否。在需要达成共识的问题上，此投票被视为否决。所有否决都必须包含对否决适当性的解释。没有解释的否决无效。任何否决都不能被推翻。如果您不同意否决，您应该游说投出否决的人。打算否决行动项目的投票者应立即将他们的意见告知小组，以便尽早解决问题。
需要达成共识批准的行动项目必须至少获得3 个具有约束力的 +1 票，并且没有否决。需要多数批准的行动项目必须至少获得3 个具有约束力的 +1 票，并且+1 票比-1 票多（即，多数票，最低人数为三个正票）。所有其他行动项目都被认为具有延迟批准，直到有人投票-1，之后它们将根据行动项目的类型由共识或多数票决定。
投票在 STATUS 文件中统计，位于正在投票的行动项目旁边。所有投票必须发送到邮件列表或直接添加到该行动项目的 STATUS 文件条目中。
长期计划只是宣布小组成员正在处理与 Apache 软件相关的特定问题。这些不会进行投票，但不同意特定计划或认为替代计划更好的小组成员有义务将他们的感受告知小组。一般来说，在花费时间研究不太充分的解决方案之前，最好能听到有关替代计划的意见。
短期计划是宣布开发者正在处理一组特定的文档或代码文件，这意味着其他开发者应避免这些文件或尝试协调他们的更改。这是一种主动避免冲突和可能的工作重复的好方法。
发布计划用于让所有开发者了解何时需要发布，谁将是发布经理，何时将冻结仓库以创建发布，以及其他各种琐事，以防止我们在最后时刻互相绊倒。延迟多数（至少 3 个 x +1 且 +1 比 -1 多）决定发布计划中的每个问题。
在构建新版本（俗称 tarball）之后，必须对其进行测试，然后才能将其发布给公众。在 tarball 可以公开发布之前，需要多数批准。
Showstoppers 是需要在下一个公开版本发布之前修复的问题。它们列在 STATUS 文件中，以便集中关注该问题。当一个问题在 STATUS 中被列为 showstopper 并通过惰性共识保持这种状态时，它就成为一个 showstopper。
对 Apache 产品的更改，包括代码和文档，将作为操作项出现在几个与更改状态相对应的类别下
概念/计划：更改的想法或计划。这些通常只在 STATUS 中列出，当更改重大、对 API 产生重大影响或可能引起争议时。早期请求投票是为了在完成太多工作之前发现冲突。
建议补丁：对当前产品的特定更改集，以 patch 命令的输入（diff 输出）的形式。
已提交的更改：自上次公开发布以来已提交到存储库的更改的单行摘要。对当前活动存储库的所有产品更改都受惰性共识的约束。对先前分支（旧版本）存储库的所有产品更改都需要在更改提交之前达成共识。
回退：回退是指将 Subversion 存储库主干上的更改应用到项目的维护分支。当 Apache HTTP Server 的多个版本中存在问题时，这很有必要。此类问题的修复通常会针对正在积极开发的主干进行开发。
想法必须先审查后提交；补丁可以先提交后审查。在先提交后审查的过程中，我们相信进行提交的开发人员对更改有高度的信心。有疑问的更改、新功能和大型改造需要在提交到存储库之前进行讨论。任何影响可配置指令参数语义、显着增加程序运行时大小或更改现有 API 函数语义的更改都必须在提交之前在邮件列表中获得共识批准。
每个开发人员都有责任在他们有关于产品的新功能或重大更改的想法时通知邮件列表并在 STATUS 中添加操作项。Apache 项目的分布式性质要求提前 48 小时通知，以便适当地审查重大更改——在更改可以提交之前，需要对概念或特定补丁达成共识批准。请注意，成员可能会否决概念（并提供充分的解释），但如果特定补丁满足了他们的反对意见，他们可能会撤销该否决。提交单个错误修复不需要提前通知。
相关的更改应作为一组提交，或非常接近地提交。未完成的项目不应提交，除非这样做对于将接力棒传递给另一位同意在短期内完成项目的开发人员是必要的。所有代码更改都必须在提交之前在开发人员的平台上成功编译。
当前的源代码树应始终能够完全编译。但是，有时开发人员在一个平台上不可能避免在提交更改时破坏另一个平台，尤其是在完成更改需要访问该另一个平台上的特殊开发工具时。如果预计给定的更改将破坏另一个平台，则提交者必须在提交日志中说明这一点。
提交者对他们提交到存储库的任何第三方代码或文档的质量负责。提交到存储库的所有软件都必须受 Apache LICENSE 涵盖，或者包含允许在与 Apache LICENSE 相同条件下重新分发的版权和许可。
如果已提交的更改被投票成员之一否决，并且否决条件不能立即通过等效于“错误修复”提交来满足，则必须撤销该更改。在更改可以包含在任何公开版本中之前，必须撤销否决。
许多代码更改应在 CHANGES 文件中注明，所有更改都应在 Subversion 提交消息中记录。通常，Subversion 日志的文本和 CHANGES 条目是相同的，但不同的要求有时会导致不同的信息。
Subversion 提交日志消息包含以下信息：
其他开发人员或研究源代码更改/修复的其他人员
最终用户（至少指出对最终用户的影响；它不必用最友好的措辞）
如果代码更改由非提交者提供，请使用 Submitted-by 进行归属。如果更改按原样提交，请使用 Reviewed-by 标识审查过它的提交者。如果更改已提交并进行了修改，请使用适当的措辞来记录这一点，例如，如果进行提交的人员进行了更改，则使用“提交并进行了更改”，或者如果其他人对提交的代码做出了贡献，则使用“提交并获得了 xxxx 的贡献”。
示例日志消息
检查解析内容长度的返回值，以避免请求包含无效内容长度时崩溃。
PR: 99999
提交者：Jane Doe <janedoe example.com>
审阅者：susiecommitter
在对 STATUS 进行例行更新时，提交消息可以很简短，例如，建议回退或投票。
CHANGES 是最终用户在从一个版本升级到下一个版本时需要查看的信息的子集
我现在可以做什么以前做不到的事情
我们预计用户可能遇到的哪些问题现在已修复
包含所有安全修复，并附带 CVE 编号。（如果在提交时不可用，请稍后添加。）
当添加对少数人有用或与评估新版本无关的信息时，CHANGES 对最终用户的可用性会降低。具体来说
上次发布后引入的错误修复不属于 CHANGES。
我们预计没有人注意到的错误修复不属于 CHANGES。（对于外部贡献，稍微弯曲一下规则，因为提交者可能需要看到他们的名字出现在灯光下，作为他们努力的回报，这些努力通常是在没有保证任何提交者会感兴趣的情况下进行的。）
文档修复，无论是针对最终用户还是开发人员，都不属于 CHANGES。
CHANGES 适用于 alpha 版本之间的更改，因此将更改从主干回退到稳定版本通常不需要从主干的 CHANGES 文件中删除该更改。
更改的归属是任何对代码更改负责的人。
使用姓名标识非提交者，如果可用，请使用模糊形式的电子邮件。模糊化是通过将“@”替换为空格并在地址周围添加“<”和“>”来完成的。例如，将 user@example.com 更改为 <user example.com>。
使用 Apache 用户 ID 标识提交者，例如 xyz（不需要域名）。
如果更改与 bugzilla 问题相关，请在日志中以以下格式包含 PR 编号
PR 1234
与安全相关的更改应以以下方式开始
*) SECURITY: CVE-YYYY-NNNN (cve.mitre.org)
xxxxx
大多数更改都插入到 CHANGES 文件的顶部。但是，与安全相关的更改应始终位于相关版本的更改列表的顶部，因此，如果文件顶部有未发布的安全更改，请将其他更改插入到它们下方。
示例 CHANGES 条目
*) SECURITY: CVE-2009-3095 (cve.mitre.org)
mod_proxy_ftp: sanity check authn credentials.
[Stefan Fritsch <sf fritsch.de>, Joe Orton]
*) SECURITY: CVE-2016-1546 (cve.mitre.org)
mod_http2: restricting number of concurrent stream workers per connection if client is slow.
开源项目，无论是 ASF 还是其他项目，都有不同的漏洞修复提交程序。这些程序的一个重要方面是，是否可以将漏洞修复提交到存储库，并附带提交日志和 CHANGES 条目，这些日志和条目有意模糊漏洞并省略任何可用的漏洞跟踪信息。Apache HTTP Server 项目已决定，对任何分支进行此类代码更改的初始提交将提供当时可用的最佳描述以及任何可用的跟踪信息，例如 CVE 编号，这对我们的用户来说是最有利的。提交修复将延迟，直到项目确定可以共享有关该问题的全部信息。
在某些情况下，即使无法共享有关该问题的全部信息，尽早共享代码也有很多实际好处，包括更广泛的审查、测试和修复分发的可能性。但这与以下担忧相抵触：仅共享代码更改允许熟练的分析师确定影响和利用机制，但并不允许普通用户社区确定是否应采取预防措施。
如果在确定错误可利用之前提交修复，从而部分披露漏洞，则 httpd 安全团队将根据具体情况决定何时记录安全影响和跟踪编号。
当在邮件列表中提出对软件的特定更改进行讨论或投票时，应以 patch 命令的输入形式呈现。发送到邮件列表时，消息应包含以 [PATCH] 开头的主题和与该补丁的操作项相对应的独特单行摘要。之后，STATUS 文件中的补丁摘要应更新为指向该消息的 Message-ID。
补丁应通过使用 diff -u 命令从原始软件文件到修改后的软件文件创建。例如，以下之一
diff -u http_main.c.orig http_main.c >> patchfile.txtsvn diff http_main.c >> patchfile.txt解决操作项所需的所有补丁应在一个补丁消息中连接起来。如果后来需要修改补丁，则应发布整个新补丁，而不仅仅是两个补丁之间的差异。然后，STATUS 文件条目应更新为指向新的补丁消息。
在目标存储库中发出以下命令时，完成的 patchfile 不应产生任何错误或提示：patch -s < patchfile
本文档中存在的问题
我们可能需要对“惰性共识”给出更好的定义。
我们应该澄清在什么情况下可以撤销或覆盖否决。
我们是否应该为补丁的否决设置时间限制？两周？