剖析Docker项目的组织架构

jopen 9年前

DockOne的肖远昊组织翻译了Docker官方的Maintainer文档，以便让大家更好的了解Docker的组织架构。官方的 Maintainer文档看起来比较乱，所以我们也调整了格式。官方文档之所以无序，是因为他们还考虑到便于程序去解析，所以如何你想了解 Maintainer的信息，可以写个程序去解析（基于TOML的解析器即可）这个文件。

DockOne组织翻译了Docker官方的Maintainer文档，以便让大家更好的了解Docker的组织架构。官方的Maintainer文档看起来比较乱，所以我们也调整了格式。官方文档之所以无序，是因为他们还考虑到便于程序去解析，所以如何你想了解Maintainer的信息，可以写个程序去解析（基于TOML的解析器即可）这个文件。

Docker有多个类型的Maintainer，他们分别承担了不同的职责。但是所有的Maintainer都有三个共同点：

  1. 他们都很关心项目的成败。
  2. 他们需要长期为项目投入很多的时间。
  3. 他们需要做那些必须要做的事情，而不是那些最有意思的事情。

可能很少会有人去夸赞Maintainer，因为他们大多都是默默无闻的工作着，修改Bug、稳步提高性能、保证某个版本的可靠性....但我们要知道，Maintainer做的事情是最最重要的事情。

Docker使用的是高效，但不完全公平的管理体系，在整个项目中，有一个仁慈的独裁者（BDFL）的角色，当然他就是Solomon Hykes（Docker之父）。也就是说，所有的决策都是由Solomon做的，但Solomon肯定没那么多精力，所以在实践中，决策就延伸到了各种 Maintainer身上。

实际上，BDFL角色就像英国女王：拥有令人敬畏的王冠，却不是日常进行运营的角色。一个BDFL的真实工作就是『永远不能离开』。其他的每一项规则或许可以彻底改变，但是BDFL必须保持项目的哲学和原则，保有决定其命运的最终权威。这种方式让我们可以灵活地尝试不同管理模型，让我们可以经常按下『重置按钮』而不用担心分裂或者死锁。当然我们可以将美国国会当成一个反例。

BDFL的日常工作包括：
  • 项目治理是否卡在了一个死锁上或者可能有其他问题（irreversibly fragmented）？如果是，BDFL将重构项目的管理方式。
  • 是否有一些逐步升级的核心问题或冲突？如果有，解决他们。
  • 擦亮自己的王冠。

那Maintainer或者BDFL如何做决策了？官方的回答是『EVERYTHING IS A PULL REQUEST』。

Docker是一个拥有开源设计哲学的开源项目，也就是说代码仓库就可以提现这些设计，包括它的哲学、设计、路线图和API。如果它是这个项目的一部分，它就在代码库中。如果它在代码库中，它就是这个这个项目的一部分。

结果，随着代码库的变化，所有的决策都能被表述。一个改变的实现就是源码的一个改变。一个API的改变就是API说明书的一个改变。一个哲学的改变就是哲学宣言上的一个改变等等。

所有决策都影响着Docker，不论大与小，都需要遵循3个相同的步骤：
  • 第一步：打开一个pull request。任何人都能做到这一点。
  • 第二步：讨论这个pull request。任何人都能做到这一点。
  • 第三步：合并或者拒绝这个pull request。谁来做这一点是依赖于这个pull request的本质以及它将影响这个项目的哪个方面。详情请见review flow。

由于Docker是一个庞大且活跃的项目，因此每个人都需要知道谁负责决定哪个方面，这是由一套明确的规则来决定的。
  • 对于这个项目的每一个决策，规则需要使用一种确定性的方式指派负责决定决策的人。
  • 对于这个项目的每一个难题，规则需要使用一种确定性的方式指派负责修复难题的人。
  • 对于这个项目的每一个问题，规则需要使用一种确定性的方式指派负责回答问题的人。

Pull Request应该根据以下流程进行处理：
  • 如果PR会影响到子系统，那子系统的Maintainer必须接受或者拒绝这次更新。子系统的Maintainer有责任及时处理对他们有影响的补丁。
  • 如果代码更新所影响到的不是一个子系统的某一部分，或者子系统Maintainer不能及时做出决定，那么这次更新必须由Maintainer来接受。
  • 如果代码更新影响的是用户接口或者公共API，或者它代表体系结构上的一个主要更新，那么必须由架构师们接受或者拒绝这次更新。
  • 如果代码更新影响到项目的运营，那么它必须由相关的运营人员接受或者拒绝。
  • 如果代码更新影响到了项目的管理，哲学，目标或者规则，它必须由BDFL来接受。
  • 一个pull request可能是以上五种不同情形中的一种，对于每一种情形都需要加上相应的标签。Rule.review.states包括了每一种情形可能的目标列表。它们分别是：Triage、Design review、Code review、Docs review、Merge。

Docker的组织架构

1. BDFL（仁慈的独裁者，女王）
BDFL由Shykes（Solomon Hykes）担任。同样，作为首席架构师，他负责所有子系统技术架构的全局完整性，以及API与UI的一致性。UI、公共API和全局架构（比如说嵌入式系统）的更新都需要由首席架构师来接受。

2. 首席运营官
目前由spf13担任，负责项目的日常运营，包括：
  • 促进所有贡献者之间的沟通；
  • 跟踪发行日程；
  • 负责下游分发与上游依赖之间的关系；
  • 帮助新贡献者的介入，并帮助他们成为贡献者和Maintainer。
  • 负责管理和评测项目整体上的成功，并配合Docker治理咨询委员会（DGAB）的工作。

3. 运营

运营人员确保『火车』准点出发。他们负责项目的全局运作。这包括促进所有参与者之间的交流；帮助新人加入并成为贡献者、Maintainer；跟踪发行日程；管理下游分发与上游依赖之间的关系；制定项目成功的评测标准并衡量进度；设计和实现那些让贡献者和Maintainer更开心，更有效率的工具与过程。

4. 首席Maintainer

目前由crosbymichael担任。首席Maintainer负责项目各方面的质量，包括代码检查、可用性、稳定性、安全性、性能等。首席Maintainer需要以榜样来领导别人。所以对于一个新的Maintainer的第一天，最好的建议是向首席Maintainer学习如何工作。

5. 核心Maintainer

核心Maintainer就是项目的ghostbusters，如果有一个其他人都没法解决的难题，那么他们就会出面解决这个难题。他们对技术实施和编码风格具有最终决定权。他们负责代码的所有形式有最终的责任：可用性的改进，bug的修复，性能，稳定性等等。当所有权能够清晰地传递到一个子系统时，他们要负责这些东西并保持子系统Maintainer的责任感。如果所有权不明确，他们就是实际的拥有者。对于每个发行版（包括次要发行版），需要在核心Maintainer中分配一个 "release captain"。 鼓励在所有Maintainer中进行轮换，来确保发行过程的清晰与最新。核心Maintainer共同的特点是可以通过"branch out"来加入或者开启一个子系统。

6. Subsystems

随着项目的推进，Docker将被分割成更恰当定义的子系统。其中每个子系统都有一组专属的Maintainer，他们致力于这个子系统并负责它的质量。

各个子系统Maintainer的责任如下：
  1. 公布一个清晰的路线图。
  2. 对于影响他们子系统的pull request，需要迅速反馈并决策。
  3. 重视所有的问题、Bug、批评等等。收集渠道包括IRC、GitHub Request和邮件列表。
  4. 确保他们的子系统遵守项目的哲学、设计和路线图。

7. Curator（监护者）

监护者会将收到的问题和pull request分类，借助他们对代码仓库活动的认知，他们能够引导贡献者到相关资料和讨论上。他们从不进行代码或者文档的检查，因此他们从来都不能进行代码的合并。但是他们能够做到：
- 当一个问题或者pull request重复，他们可以关闭它。
- 当一个问题或者pull request不太合适或者离题了，他们可以关闭它。

来自：http://dockerone.com/article/340