社区角色 ¶

提交者 ¶

Subversion 项目的提交者是指那些被授予直接提交更改到我们版本控制资源的权利的人。该项目是精英制的，这意味着（除其他事项外）项目治理由那些做工作的人来处理。提交访问权限有两种类型：完全访问权限和部分访问权限。完全访问权限是指树中的任何位置，部分访问权限是指提交者特定专业领域。虽然每个贡献都受到重视，无论其来源如何，但并非每个为 Subversion 贡献代码的人都会获得提交访问权限。

COMMITTERS 文件列出了所有提交者，包括完全提交者和部分提交者，并说明了每个部分提交者的域。

如何获得完全提交访问权限 ¶

当某人成功贡献了几个非微不足道的补丁后，通常是审核并应用了该贡献者最多补丁的完整提交者会提议授予他们提交权限。该提议仅发送给其他完整提交者 - 随后的讨论是私密的，以便每个人都能坦诚地表达自己的意见。假设没有异议，则会授予贡献者提交权限。该决定由共识做出；没有正式的规则来管理该程序，但通常如果有人强烈反对，则不会提供访问权限，或者以临时方式提供。

获得完整提交权限的主要标准是良好的判断力。

您不必成为技术奇才，也不必展示对整个代码库的深入了解，就能成为完整提交者。您只需要知道自己不知道什么。如果您的补丁符合本文件中的指南，遵循所有通常的不可量化的编码规则（代码应可读、健壮、可维护等），并尊重“首先，不伤害”的希波克拉底原则，那么您可能会很快获得提交权限。补丁的大小、复杂性和数量并不像您在避免错误和最大程度地减少对代码其余部分的不必要影响方面所表现出的谨慎程度那样重要。许多完整提交者并没有做出主要的代码贡献，而是做了很多小的、干净的修复，每一个都是对代码的明确改进。（当然，这并不意味着项目需要一堆非常微不足道的补丁，其唯一目的是获得提交权限；知道什么值得发布补丁，什么不值得，是展示良好判断力的一部分 :-)）。

为了帮助开发人员发现新的提交者，我们在特殊的贡献格式中记录了补丁和其他贡献，然后解析这些格式以生成一个浏览器友好的贡献列表，该列表每晚更新。如果您正在考虑提议某人获得提交权限，并希望查看他们所有的更改，那么贡献列表可能是最方便的地方。

如何授予部分提交权限 ¶

完整提交者会赞助部分提交者。通常这意味着完整提交者已经从提议的部分提交者那里应用了几个针对同一区域的补丁，并且意识到如果该人直接提交，事情会更容易。赞助者在发出邀请之前，通常会向 private@ 提出建议，但并非强制要求；信任赞助者会做出良好的判断。

赞助者会观察部分提交者的前几次提交，以确保一切顺利进行。

由部分提交者提交的补丁，即使超出该人员的领域，也可以由该提交者提交。这需要至少一名完整提交者的批准（通常以 +1 票表示）。在这种情况下，应在日志消息中注明批准，如下所示

   Approved by: lundblad

任何完整提交者都可以随时为任何人提供实验分支的提交权限。实验分支不一定有很高的合并到主干的可能性（尽管这始终是一个值得追求的目标）。同样重要的是，完整提交者——实际上所有完整提交者——将这些分支视为新开发人员的训练场，通过对提交进行反馈。这些分支的目标是将新代码引入 Subversion 并将新开发人员引入项目。另请参阅有关轻量级分支的部分，以及这封邮件

   https://svn.haxx.se/dev/archive-2007-11/0848.shtml
   From: Karl Fogel <[email protected]>
   To: [email protected]
   Subject: branch liberalization (was: Elego tree conflicts work)
   Date: Tue, 20 Nov 2007 10:49:38 -0800
   Message-Id: <[email protected]>

contrib/ 区域 ¶

当一个工具被接受到 contrib/ 区域时，我们会自动为其作者提供部分提交权限，以便在那里维护该工具。任何完整提交者都可以赞助此操作。通常不需要讨论或投票，但如果有异议，则适用通常的决策程序（首先尝试达成共识，如果无法达成共识，则在完整提交者之间进行投票）。

contrib/ 下的代码必须是开源的，但不需要与 Subversion 本身具有相同的许可证或版权持有者。

“明显修复”规则 ¶

任何提交者，无论是完整提交者还是部分提交者，都可以修复任何地方的明显拼写错误、语法错误和格式问题——在网页、API 文档、代码注释、提交消息等中。我们依赖提交者的判断来确定什么是“明显的”；如果您不确定，请询问。

无论何时您调用“明显修复”规则，请在您的提交的日志消息中说明。例如

------------------------------------------------------------------------
r32135 | stylesen | 2008-07-16 10:04:25 +0200 (Wed, 16 Jul 2008) | 8 lines

Update "check-license.py" so that it can generate license text applicable
to this year.

Obvious fix.

* tools/dev/check-license.py
  (NEW_LICENSE): s/2005/2008/

------------------------------------------------------------------------

访客提交者 ¶

Subversion 是ASF的一部分，与 100 多个其他 ASF 项目共享同一个存储库。虽然那些项目上的提交者不被视为 Subversion 的完整提交者或部分提交者，但他们欢迎提交明显的修复，以及他们提交的补丁——前提是这些补丁已获得完整提交者（或其领域内的部分提交者）的 +1。在这两种情况下，请遵循我们的日志消息指南。

发布经理 ¶

在 Subversion 项目中，发布经理的角色是负责处理将代码稳定化、打包并发布给公众的过程。如果我们正在建造飞机，发布经理就是负责检查施工清单、在机身喷涂航空公司标志，并将完成的飞机交付给客户的人。

因此，作为发布经理并没有真正的开发工作。你所要做的都是非编码工作：协调人员、集中信息，并作为公众代言人宣布新的稳定版本。发布经理需要完成很多重复性任务，这些任务要么是因为还没有人开发出工具而无法自动化，要么是因为这些任务需要人工验证，自动化显得有些多余。你可以在发布 Subversion 版本部分了解更多关于发布流程的信息。

你可能在想，发布经理的职责并不光彩，你有点对了。如果你想在项目中找到一个能带来名利的位置，你最好去实现 trunk 上真正需要完成的东西。如果你想找一些真正能帮助那些不关心发布的人专注于代码的工作，那么发布经理就是你的选择。

为了鼓励更广泛地传播发布管理知识，发布经理的角色目前正在各个 ~~受害者~~ 志愿者之间轮换。

补丁经理 ¶

Subversion 通常有一个补丁经理，其工作是监视 dev@ 邮件列表，确保没有补丁“漏网”。

这意味着要监视所有包含“[PATCH]”邮件的主题，并根据主题的进展采取相应的行动。如果主题自行解决（因为补丁被提交，或者因为大家一致认为不需要应用补丁，或者其他原因），则无需采取进一步行动。但如果主题在没有明确决定的情况下消失，则需要将补丁保存到问题跟踪器中。这意味着需要在跟踪器中的某个问题中添加对该补丁周围任何讨论主题的摘要以及相关邮件列表存档的链接。对于解决现有问题跟踪器项目的补丁，将该补丁保存到该项目中。否则，将创建一个新的正确类型的问题——“DEFECT”、“FEATURE”或“ENHANCEMENT”（不是“PATCH”），将补丁保存到该新问题中，并将“patch”关键字记录到该问题中。

补丁经理需要对 Subversion 有基本的技术理解，并能够快速浏览主题，大致了解是否达成共识，以及达成什么样的共识。它不需要实际的 Subversion 开发经验或提交权限。使用邮件阅读软件的专业知识是可选的，但建议使用 :-）。

当前的补丁管理器是：Gavin 'Beau' Baumanis <[email protected]>。