FreeBSD 项目模型
FreeBSD 项目的项目模型
版权 © 2002-2005 Niklas Saers
前言
到目前为止，FreeBSD 项目已发布了许多描述不同工作部分的技术。然而，由于项目成员数量不断增加，需要一个总结项目结构的项目模型。^[1]^ 本文将提供这样一个项目模型，并捐赠给 FreeBSD 文档项目，以便与项目一起发展，从而随时反映项目的工作方式。它基于[ Saers,2003]。
我想感谢以下的人，他们花时间为我解释不清楚的事情，并校对文件。
Andrey A. Chernov ache@freebsd.org
Bruce A. Mah bmah@freebsd.org
Dag-Erling Smørgrav des@freebsd.org
Giorgos Keramidas keramida@freebsd.org
Ingvil Hovig ingvil.hovig@skatteetaten.no
Jesper Holck jeh.inf@cbs.dk
John Baldwin jhb@freebsd.org
John Polstra jdp@freebsd.org
Kirk McKusick mckusick@freebsd.org
Mark Linimon linimon@freebsd.org
Marleen Devos
Niels Jørgenssen nielsj@ruc.dk
Nik Clayton nik@freebsd.org
Poul-Henning Kamp phk@freebsd.org
Simon L. Nielsen simon@freebsd.org
1. 概述
项目模型是减少项目中的沟通开销的一种手段。正如[Brooks, 1995]所示，增加项目参与者的数量会呈指数级增加项目中的沟通。在过去几年中，FreeBSD 的活跃用户和提交者数量都在增加，项目中的沟通也相应增加。该项目模型将通过提供项目的最新描述来减少这种开销。
在 2002 年的 Core 选举中，Mark Murray 表示“我反对一部冗长的规则书，因为那满足了律师的倾向，与项目非常需要的技术中心相悖。”[FreeBSD, 2002B]。这个项目模型并不是为了为开发人员创造强制性规定的工具，而是作为促进协调的工具。它旨在描述项目，概述不同流程的执行方式。它是对 FreeBSD 项目如何运作的介绍。
自 2004 年 7 月 1 日起，将描述 FreeBSD 项目模型。基于 Niels Jørgensen 的论文[Jørgensen，2001]，FreeBSD 的官方文件，FreeBSD 邮件列表上的讨论以及与开发人员的采访。
在提供使用术语的定义后，本文将概述组织结构（包括角色描述和沟通线路），讨论方法论模型，并在介绍用于过程控制的工具后，将呈现定义的过程。最后，它将概述 FreeBSD 项目的主要子项目。
[自由贝获得, 2002A] 第 1.2 节和 1.3 节提供了项目的愿景和架构指南。愿景是“以最大限度地尊重原始软件工具意识形态以及可用性、性能和稳定性为目标，生产可能的最佳类 UNIX 操作系统软件包。”架构指南有助于确定某个希望解决的问题是否属于项目的范围。
2. 定义
2.1. 活动
"活动"是项目过程中执行的工作要素[PMI，2000]。它具有输出并导向结果。这样的输出可以是另一个活动的输入，也可以是流程交付的一部分。
2.2. 过程
"过程"是一系列导向特定结果的活动。一个过程可以包含一个或多个子过程。过程的一个例子是软件设计。
2.3. 帽子
“帽子”是角色的同义词。帽子在一个过程中具有一定的责任和结果。帽子执行活动。项目成员和项目外部的人应联系帽子处理哪些问题是明确规定的。
2.4. 结果
一个“结果”是流程的最终输出。这与可交付成果同义，被定义为“任何可衡量、可触及、可验证的结果、成果或项目，必须生产以完成项目或项目的一部分。通常更狭义地用于指外部可交付成果，即受项目发起人或客户批准的可交付成果” [ PMI，2000]。结果的例子包括软件、决策或报告的撰写。
2.5. FreeBSD
当说到“FreeBSD”时，我们指的是 BSD 衍生的类 UNIX 操作系统 FreeBSD，而当说到“FreeBSD 项目”时，我们指的是项目组织。
3. 组织结构
虽然没有人拥有 FreeBSD，但 FreeBSD 组织分为核心、提交者和贡献者，并且是围绕它生活的 FreeBSD 社区的一部分。
FreeBSD 项目的结构（按降序权限排列）
核心成员
9
贡献者
318
贡献者
~3000
通过查阅 2004 年 1 月 1 日至 2004 年 12 月 31 日的 CVS 日志，已确定贡献人数；通过查阅贡献清单和问题报告，已确定贡献者人数。
FreeBSD 社区中的主要资源是其开发人员：提交者和贡献者。正是凭借他们的贡献，项目才能向前发展。常规开发人员被称为贡献者。截至 2003 年 1 月 1 日，估计有 5500 名贡献者参与该项目。
提交者是具有提交更改权限的开发人员。这些通常是最活跃的开发人员，他们愿意花时间不仅集成自己的代码，还集成那些没有此权限的开发人员提交的代码。他们还是选举核心团队的开发人员，并且可以访问封闭讨论。
该项目可以分为四个明确的独立部分，大多数开发人员将专注于 FreeBSD 的一个部分。这四个部分分别是内核开发，用户空间开发，ports 和文档。在提到基本系统时，内核和用户空间都是指的。
这个拆分会使我们的表格变成这样：
FreeBSD 项目的结构和类别中的合作者
核心成员
9
提交者
Base
164
Docs
45
Ports
166
总数
374
贡献者
~3000
每个区域的 Committer 数量是通过查看从 2004 年 1 月 1 日到 2004 年 12 月 31 日的 CVS 日志进行确定的。请注意，许多 Committer 在多个区域工作，使得实际 Committer 数量比实际 Committer 数量要高。2022 年 6 月活跃的独特 Committer 总数为 317。
Committers 分为三组：只关注项目的一个区域（例如文件系统）的 Committer，只涉及一个子项目的 Committer，以及向代码不同部分（包括子项目）进行提交的 Committer。由于一些 Committer 在不同部分工作，因此表中 Committer 部分的总数比上表中的要高。
内核是 FreeBSD 的主要构建模块。虽然用户态应用程序受到其他用户态应用程序中的错误的保护，但整个系统对内核中的错误是脆弱的。这与内核中大量的依赖项以及不容易看到内核更改的所有后果相结合，要求开发人员对内核有相对全面的理解。内核中的多个开发工作还需要比用户态应用程序更紧密的协调。
用户空间提供了被称为用户界面的核心实用工具，识别 FreeBSD 的接口，包括用户界面、共享库和外部接口，用于连接客户端。目前，有 162 人参与用户空间的开发和维护，其中许多人是自己代码部分的维护者。维护将在维护部分讨论。
文档由 FreeBSD 文档项目处理，包括围绕 FreeBSD 项目的所有文档，包括网页。在 2004 年，有 101 人向 FreeBSD 文档项目提交了内容。
Ports 是在 FreeBSD 上使软件包正确构建所需的元数据集合。一个 port 的示例是 Web 浏览器 Mozilla 的 port。它包含关于从哪里获取源代码、应用哪些修补程序以及如何在系统上安装软件包的信息。这使得自动化工具可以获取、构建和安装软件包。截至本文撰写时，有超过 12600 个 ports 可用，其中涵盖了从 Web 服务器到游戏、编程语言以及现代计算机上使用的大多数应用类型。Ports 将在“Ports 子项目”部分进一步讨论。
4. 方法论模型
4.1. 发展模型
FreeBSD 中写代码的人没有定义的模型。然而，Niels Jørgenssen 提出了一个关于如何将编写的代码整合到项目中的模型。
Jørgenssen 的变革整合模型
代码
审查
复查
预提交测试
代码
预提交测试
发布版本开发
代码
开发版本发布
并行调试
代码
并行调试
生产发布
代码
生产发布
代码
“开发版本”是 FreeBSD-CURRENT（“-CURRENT”）分支，“生产版本”是 FreeBSD-STABLE 分支（“-STABLE”）[Jørgensen，2001]。
这是一个关于变更的模型，显示了在编码后，开发人员寻求社区审查并尝试将其与自己的系统集成。在将变更集成到名为 FreeBSD-CURRENT 的开发版本后，它会被 FreeBSD 社区中的许多用户和开发人员测试。经过足够的测试后，它将被合并到名为 FreeBSD-STABLE 的生产版本中。除非每个阶段都成功完成，开发人员需要返回并在代码中进行修改，然后重新启动流程。将变更与-CURRENT 或-STABLE 集成称为提交。
Jørgensen 发现大多数 FreeBSD 开发人员是独立工作的，这意味着许多开发人员在不同的正在进行的开发工作中并行使用这个模型。开发人员也可以同时处理多个变更，因此当他们在等待审查或其他人测试他们的一个或多个变更时，他们可能正在编写另一个变更。
每个提交代表一个增量，这是一个大规模的增量模型。实际上，提交是如此频繁，以至于在一年内^[ 3]^，共进行了 85427 次提交，平均每天 233 次提交。
在 Jørgensen 模型中的 "code" 范围内，每个程序员都有自己的工作方式，并遵循自己的开发模型。这个范围完全可以称为 "development"，因为它包括需求收集与分析、系统和详细设计、实施和验证。然而，这些阶段的唯一输出是源代码或系统文档。
从分步模型（如瀑布模型）的角度来看，其他范围可以看作是进一步的验证和系统集成。这个系统集成对于查看社区是否接受变更也很重要。在代码提交之前，开发人员可以自由选择与项目其他部分沟通的程度。为了使 -CURRENT 作为缓冲区（这样可以撤销那些有未发现缺陷的好主意），在合并到 -STABLE 之前，提交在 -CURRENT 中的最短时间应为 3 天。这样的合并称为 MFC（从 CURRENT 合并）。
需要注意的是 "change" 一词。大多数提交不包含根本性的新增功能，而是维护更新。
该模型的唯一例外是针对安全修复和在当前分支中已弃用的功能所做的更改。在这些情况下，更改可以直接提交到稳定分支。
除了许多参与该项目的人之外，FreeBSD 项目还有许多相关项目。这些项目要么是开发全新功能的项目，要么是子项目，或者是项目的成果被整合到 FreeBSD 中^[ 4]^。这些项目与 FreeBSD 项目的关系与常规开发工作类似：它们生成的代码会与 FreeBSD 项目集成。然而，其中一些项目（如 Ports 和文档）有特权直接适用于当前分支和稳定分支。
关于设计的标准并不存在，设计也没有集中存储在一个仓库中。主要设计是 4.4BSD 的设计^[ 5]^。由于设计属于 Jørgenssen 模型中的"代码"部分，每个开发人员或子项目可以自行决定如何进行设计。即使设计应该存储在中央仓库中，设计阶段的输出也将用处有限，因为各种方法的差异将使它们很少甚至根本无法互操作。对于项目的整体设计，项目依赖于子项目之间协商适当接口，而不是强行规定接口。
4.2. 发行分支
FreeBSD 的发布最好通过一棵树来说明，其中有许多分支，每个主要分支代表一个主要版本。次要版本由主要分支的分支代表。
在下面的发布树中，沿特定方向依次跟随的箭头表示一个分支。具有实线和菱形的框表示官方发布。具有虚线的框表示该时期的开发分支。安全分支由椭圆形表示。 菱形不同于框，因为它们代表一个分岔口，表示一个分支分成两个分支的地方，其中一个分支变成子分支。 例如，在 4.0-RELEASE 时，4.0-CURRENT 分支分成 4-STABLE 和 5.0-CURRENT。 在 4.5-RELEASE 时，该分支分叉出一个名为 RELENG_4_5 的安全分支。
图 1. FreeBSD 发行树
…
3.0 当前（开发分支）
Releng 3 branches: 3.0 Release to 3.5 Release, leading to 3.5.1 Release and the subsequent 3 Stable branch
4.0 Current (development branch)
3.1 Release
Releng 4 branches: 4.1 Release to 4.6 Release (and 4.6.2 Release), then 4.7 Release to 4.11 Release (all starting at 4.3 Release also leading to a Releng_4_n branch), and the subsequent 4 Release branch
5.0 Current (development branch)
4.0 Release
Releng 5 branches: 5.0 发布到 5.4 发布（除了 5.0 和 5.3 之外，还导致 Releng_5_n 分支），以及随后的 5 发布分支
6.0 当前（开发分支）
5.3 发布
…
最新的-CURRENT 版本始终被称为-CURRENT，而最新的-STABLE 版本始终被称为-STABLE。在这个图中，-STABLE 指的是 4-STABLE，而-CURRENT 指的是 5.0-CURRENT，接下来是 5.0-RELEASE。【FreeBSD，2002E】
“主要版本”总是从-CURRENT 分支制作。然而，-CURRENT 分支在那个时候不需要分叉，而可以专注于稳定。一个例子是，在 3.0-RELEASE 之后，3.1-RELEASE 也是-CURRENT 分支的延续，并且直到这个版本发布和 3-STABLE 分支被分叉之前，-CURRENT 才不会成为真正的开发分支。当-CURRENT 重新变成开发分支时，只能接下来是一个主要版本。预计 5-STABLE 将在 5.3-RELEASE 左右从 5.0-CURRENT 分叉。直到 5-STABLE 被分叉，开发分支才会被标记为 6.0-CURRENT。
从主要版本发布后的-CURRENT 分支或者-STABLE 分支制作一个"次要版本"。
从 4.3-RELEASE^[ 6]^开始，当制作了一个次要版本后，它就变成了一个"安全分支"。这是为那些不想跟随-STABLE 分支及其可能提供的新功能/更改，而是需要一个绝对稳定的环境，只更新以实施安全更新的组织而设立的。^[ 7]^
对安全分支的每次更新称为"补丁级别"。对于每项安全增强措施，补丁级别编号都会增加，这样跟踪该分支的人就可以看到他们已经实施了哪些安全增强措施。在存在特别严重的安全漏洞的情况下，可以从安全分支制作一个全新的发布版本。一个例子是 4.6.2-RELEASE。
4.3. 模型摘要
总之，FreeBSD 的开发模型可以被看作是以下树：
图 2. 总体开发模型
FreeBSD 开发的树，其中进行持续的开发工作和持续集成。
该树象征着发布的版本，其中主要版本衍生出新的主分支，次要版本是主分支的版本。顶部分支是-CURRENT 分支，所有新开发都集成在这里，-STABLE 分支是直接在其下面的分支。在-STABLE 分支下面是旧的、不受支持的版本。
开发工作的云彩笼罩着项目，开发人员使用他们认为合适的开发模型。他们的工作成果随后被集成到-CURRENT 中，在那里进行并行调试，最终从-CURRENT 合并到-STABLE。安全修复程序从-STABLE 合并到安全分支。
许多提交者都有特定的责任领域。这些角色被称为帽子。这些帽子可以是项目角色，比如公共关系官，或者是某个代码区域的维护者。因为这是一个人们自愿投入业余时间的项目，担任帽子角色的人并不总是可用的。因此，他们必须任命一名代理人，在他们不在时可以执行帽子的角色。另一种选择是由一个团队担任该角色。
这些帽子中许多并没有正式化。正式化的帽子有一份宪章，说明帽子的确切目的以及其特权和责任。编写这些宪章是项目的一个新部分，因此尚未为所有帽子完成。这些帽子描述并不是这样的正式化，而是该角色的摘要，其中包含到可用的宪章和联系地址的链接。
5. 帽子
5.1. 通用帽子
5.1.1. 贡献者
贡献者以开发者、作者、发送问题报告或以其他方式促进项目进展的形式为 FreeBSD 项目做出贡献。贡献者在 FreeBSD 项目中没有特权。[FreeBSD，2002F]
5.1.2. 许可者
具备必要权限向存储库添加其代码或文档的人。过去 12 个月内曾提交过的许可者。[ FreeBSD，2000A] 活跃的许可者是在那段时间内平均每月提交一次的许可者。
值得注意的是，从技术上讲，没有任何障碍可以阻止某人一旦获得对主项目或子项目的提交权限，就在该项目源代码的部分中进行提交，即使许可者没有明确获得修改权限的这些部分。然而，当想要对许可者以前未涉足的部分进行修改时，他们应该阅读日志以查看此领域发生了什么，并且还应该阅读 MAINTAINERS 文件，看看此部分的维护人员是否对代码的更改有任何特殊要求。
5.1.3. 核心团队
核心团队由提交者从提交者池中选举产生，并担任 FreeBSD 项目的董事会。它将积极贡献者晋升为提交者，分配人员到明确定义的职责，并是涉及项目发展方向的决策的最终仲裁者。截至 2004 年 7 月 1 日，核心团队由 9 名成员组成。选举每两年举行一次。
5.1.4. 维护者身份
维护者负责确定允许输入代码的范围，并在出现关于代码的分歧时拥有最终决定权。这涉及积极的工作，旨在激发贡献，并在审查提交时进行反应性工作。
FreeBSD 源代码附带一个 MAINTAINERS 文件，其中包含每个维护者希望如何进行贡献的一句总结。拥有这些通知和联系信息使开发人员可以专注于开发工作，而不必被卡在一段时间内维护者不可用的缓慢通讯中。
如果维护者长时间不可用，并且其他人做了大量工作，则可能会在未经维护者批准的情况下更改维护者身份。这是基于维护者身份应该得到证明，而不是宣布的立场。
代码的维护者不是作为一个团体来承担的角色。
5.2. 官方角色
FreeBSD 项目中的官方角色更多或少是正式的并且主要是管理角色。他们对自己的领域有权威和责任。以下列表显示了责任线，并提供了每个角色的描述，包括持有者。
5.2.1. 文档项目经理
FreeBSD 文档项目架构师负责为文档项目中的提交者定义和跟踪文档目标，并监督他们。
由 DocEng 团队 doceng@FreeBSD.org 担任的帽子。 DocEng 宪章。
5.2.2. 邮件管理员
邮件管理员负责将邮件正确发送到提交者的电子邮件地址。他们还负责确保邮件列表正常工作，并应采取措施防止可能的邮件中断，如设置垃圾邮件、垃圾邮件和病毒过滤器。
目前由邮件管理员团队 postmaster@FreeBSD.org 担任。
5.2.3. 发布协调
发布工程团队的责任是
为官方发布设置、发布和遵循发布时间表
记录和规范发布工程流程
创建和维护代码分支
与 Ports 和文档团队协调，确保更新的软件包和文档随新版本一起发布
与安全团队协调，以确保未完成的发布不受最近披露的漏洞影响。
有关开发过程的更多信息，请参阅发布工程部分。
帽子由：发布工程团队 re@FreeBSD.org 担任。发布工程宪章。
5.2.4. 公共关系与公司联络
公共关系与公司联络的职责是：
当发生对 FreeBSD 项目重要的事情时，发布新闻声明。
作为与 FreeBSD 项目密切合作的公司的官方联系人。
采取措施在开源社区和企业界内推广 FreeBSD。
处理“freebsd-advocacy”邮件列表。
这顶帽子目前没有人佩戴。
5.2.5. 安全官员
安全官员的主要责任是协调与安全社区和 FreeBSD 项目中其他人员的信息交流。安全官员还负责在报告安全问题时采取行动，并在涉及安全时促进积极的开发行为。
由于担心漏洞信息在补丁发布之前泄露给恶意人士，只有安全官员，包括一名官员，一名副手和两名核心团队成员才能接收有关安全问题的敏感信息。但是，为了创建或实施补丁，安全官员依靠安全官员团队 security-team@FreeBSD.org 来协助完成工作。
5.2.6. 源代码库管理器
源代码库管理器是唯一被允许直接修改存储库而不使用 Git 工具的人。他们有责任确保存储库中出现的技术问题得到迅速解决。源代码库管理器有权回滚提交，以解决 Git 技术问题。
由 FreeBSD.org 的 Source Repository Manager clusteradm 持有的帽子。
5.2.7. 选举管理器
选举管理器负责核心选举过程。该管理器负责运行和维护选举系统，并且在选举过程中发生较小的意外事件时是最终权威。对于重大意外事件，必须与核心团队讨论。
只在选举期间佩戴的帽子。
5.2.8. 网站管理
网站管理帽子负责协调在全球镜像站点上更新网页的推出，为主要网站的整体结构以及运行在其上的系统。管理人员需要与 FreeBSD 文档项目协调内容，并充当“www”树的维护者。
由 FreeBSD 网站管理员 www@FreeBSD.org 所持有的帽子。
5.2.9. Ports 管理员
Ports 管理员充当 The Ports 子项目与核心项目之间的联络人，所有项目请求都应发送给 ports 管理员。
由 FreeBSD.org 的 portmgr@管理团队持有的帽子。 Portmgr 宪章。
5.2.10. 标准
负责确保 FreeBSD 遵守其承诺的标准，跟踪这些标准的发展并通知 FreeBSD 开发人员重要变化，使他们能够积极参与并减少标准更新与 FreeBSD 合规性之间的时间。
目前由 Garrett Wollman wollman@FreeBSD.org 持有的帽子。
5.2.11. 核心秘书
核心秘书的主要责任是撰写草案并发布最终的核心报告。秘书还保留核心议程，从而确保没有问题悬而未决。
目前由 René Ladan rene@FreeBSD.org持有的帽子。
5.2.12. 缺陷管理员
缺陷管理员负责确保维护数据库正常运行，条目被正确分类，并且没有无效条目。他们监督缺陷猎手。
目前由 Bugmeister 团队 bugmeister@FreeBSD.org 持有的帽子。
5.2.13. 捐赠联络官
捐赠联络官的任务是将开发人员的需求与愿意捐赠的个人或组织匹配起来。
由 FreeBSD.org 的捐赠联络办公室捐赠的帽子。捐赠联络宪章。
5.2.14. 管理员
（也称为“FreeBSD 集群管理员”）
管理团队由负责管理项目所依赖的计算机以便其分布式工作和沟通同步的人员组成。主要由那些可以接触服务器的人员组成。
Hat 由：管理员团队 admin@FreeBSD.org 持有。
5.3. 过程依赖的帽子
5.3.1. 报告发起人
最初负责提交问题报告的人。
5.3.2. Bugbuster
一个人，要么找到合适的人解决问题，要么关闭 PR，如果它是一个重复的或者其他方面不是一个有趣的。
5.3.3. 导师
导师是一个 committer，他自己介绍一个新的 committer 加入项目，无论是确保新的 committer 的设置是有效的，这位新的 committer 知道他们工作所需的可用工具，还是这位新的 committer 知道他们在行为方面期望他们做什么。
5.3.4. 供应商
外部代码来自的个人或组织，以及发送补丁的对象。
5.3.5. 审阅者
邮件列表上发布了审查请求的人。
以下部分将描述定义的项目流程。这些流程未涉及的问题将根据类似情况的惯例进行临时处理。
6. 流程
6.1. 添加新的提交者并移除旧的提交者
核心团队有责任向贡献者授予和移除提交权限。这只能通过核心邮件列表上的投票来完成。ports 和文档子项目可以向在这些项目上工作的人授予提交权限，但迄今为止尚未取消此类权限。
通常，贡献者由提交者推荐给核心。贡献者或外部人员联系核心要求成为提交者并不被认可，通常会被拒绝。
如果开发人员的特定兴趣领域可能与其他提交者的维护领域重叠，那么将征求这些维护者的意见。然而，通常是这位提交者推荐这位开发人员。
给予贡献者提交者身份时，他们会被分配一位导师。一般情况下，推荐新提交者的提交者会自愿成为新提交者的导师。
当贡献者获得他们的提交权限时，要求核心秘书、Ports 管理员或 nik@freebsd.org 发送一封通过 Pretty Good Privacy 签名的电子邮件至 admins@freebsd.org、分配的导师、新提交者和核心，确认新账户的批准。然后，导师会收集新提交者的密码行、Secure Shell 公钥和 PGP 密钥，并将它们发送给管理员。当新账户被创建时，导师会激活提交权限，并指导新提交者完成初始流程的其余部分。
图 3. 过程摘要：添加新的提交者
当贡献者发送一段代码时，接收提交者可以选择推荐给予贡献者提交权限。如果他们向核心推荐此事，核心将对此推荐进行投票。如果投票结果为赞成，导师将被指定为新的提交者，并且新的提交者必须将其详细信息发送给管理员以创建帐户。之后，新的提交者就可以进行第一次提交了。按照传统，这是通过将他们的姓名添加到提交者列表来完成的。
请记住，提交者被视为在过去 12 个月内提交过代码的人。然而，只有在 18 个月的不活动之后，提交权限才有资格被撤销。[FreeBSD，2002 年] 然而，没有自动程序来执行此操作。有关不是由时间触发的提交权限的反应，请参见第 1.5.8 节。
图 4. 过程概述：移除提交者
当 Core 决定清理提交者列表时，他们会检查过去 18 个月内没有进行提交的人员。没有提交的提交者会被撤销提交权限，并由管理员删除其账户。
提交者也可以请求撤销其提交权限，如果他们由于某种原因不再积极参与项目。在这种情况下，如果提交者提出要求，Core 也可以在以后恢复其提交权限。
这个过程中的角色:
[ 自由的 BSD，2000A ] [ 自由的 BSD，2002H ] [ 自由的 BSD，2002I ]
6.2. 提交代码
提交新代码或修改过的代码是 FreeBSD 项目中最常见的过程之一，通常会发生多次。提交代码只能由“committer”完成。Committer 可以提交自己编写的代码、提交给他们的代码，或通过问题报告提交的代码。
当开发人员编写的代码不太简单时，他们应该向社区寻求代码审查。这是通过发送电子邮件到相关列表请求审查来完成的。在将代码提交审查之前，他们应确保它与整个代码树编译正确，并且所有相关的测试都运行。这被称为“预提交测试”。收到贡献的代码后，应由提交者审查并以同样的方式进行测试。
当对来自外部供应商贡献的源代码进行更改时，维护者应确保将补丁贡献回供应商。这符合开源哲学，使得与外部项目保持同步变得更容易，因为补丁不必每次发布新版本时重新应用。
在代码已经可以审查并且不需要进一步更改之后，代码将提交到开发分支-CURRENT。如果更改也适用于-STABLE 分支或其他分支，则提交者会设置一个“从当前合并”（“MFC”）倒计时。在提交者设置 MFC 时选择的天数过后，将自动向提交者发送一封电子邮件，提醒他们将其提交到-STABLE 分支（可能也适用于安全分支）。只有安全关键更改才应合并到安全分支。
延迟提交到 -STABLE 和其他分支，可以进行“并行调试”，其中提交的代码在各种配置上进行测试。这使得对 -STABLE 的更改包含更少的错误，从而赋予分支其名称。
图 5. 流程摘要：提交者提交代码
当一名提交者编写了一段代码并希望提交它时，他们首先需要确定它是否足够简单，可以在没有事先审查的情况下提交，还是应该先由开发者社区审查。如果代码很简单或已经经过审查，并且提交者不是维护者，则在继续之前应该咨询维护者。如果代码是由外部供应商贡献的，则维护者应创建一个发送回供应商的补丁。然后提交代码，由用户部署。如果他们发现代码有问题，这将被报告，提交者可以继续编写补丁。如果供应商受到影响，他们可以选择实施或忽略该补丁。
图 6. 过程摘要: 贡献者提交代码
当贡献者进行代码贡献时的区别在于他们通过 Bugzilla 接口提交代码。维护者会审查代码并进行提交。
此过程中包括的帽子有：
[FreeBSD, 2001] [Jørgensen, 2001]
6.3. 核心选举
核心选举至少每两年举行。^[8]^ 选举产生九名核心成员。如果核心成员人数低于七人，将进行新的选举。如果至少 1/3 的活跃提交者要求，也可以进行新的选举。
当选举即将进行时，核心至少提前 6 周宣布，并任命选举经理负责选举工作。
只有提交者可以被选入核心。候选人需要在选举开始前至少一周提交他们的候选资格，但可以在投票开始前完善自己的陈述。他们将列在候选人名单中。在撰写选举声明时，候选人必须回答选举经理提出的几个标准问题。
在选举期间，严格遵循提交者必须在过去 12 个月内提交过的规定。只有这些提交者有资格投票。
在投票时，提交者可以支持最多九名候选人中的一人。投票在四周内进行，提醒将发布在“developers”邮件列表上，该列表对所有提交者开放。
选举结果将在选举结束后一周公布，新核心团队将在结果发布后一周上任。
如果投票出现平局，将由新选举产生的核心成员来解决。
投票结果和候选人声明会被归档，但这些档案不会公开。
图 7。流程摘要：核心选举
核心团队宣布选举并选出一位选举经理，后者准备选举，准备就绪后，候选人可以通过提交自己的声明来宣布自己的候选资格。然后提交者进行投票。投票结束后，选举结果将被宣布，新的核心团队将上任。
核心选举中的帽子有：
[FreeBSD, 2000A] [FreeBSD, 2002B] [FreeBSD, 2002G]
6.4. 开发新功能
在项目中，有正在开发新功能的子项目。这些项目通常由一个人完成[Jørgensen, 2001]。每个项目可以自由组织开发方式。然而，当项目合并到-CURRENT 分支时，必须遵循项目指南。当代码在-CURRENT 分支中经过充分测试并被认为足够稳定且与-STABLE 分支相关时，它将被合并到-STABLE 分支。
项目的需求由开发人员的愿望、社区的直接请求（通过邮件、问题报告）、用于功能开发的商业资助或科学界的贡献确定。属于开发人员责任范围的愿望将交给该开发人员，他们在请求和愿望之间优化自己的时间。一个常见的做法是通过项目维护一个 TODO 列表。除非有人自愿承担责任，否则所有不属于某人责任范围的请求都会被收集在 TODO 列表上。所有请求、它们的分发和后续处理都由 Bugzilla 工具处理。
需求分析以两种方式进行。讨论进来的请求在邮件列表中进行，既在主项目内部，也在请求所属的子项目或由请求引发的子项目中进行。此外，子项目上的个人开发人员将评估请求的可行性，并确定它们之间的优先级。除了讨论的存档外，此阶段没有创造出合并到主项目的结果。
由于个体开发人员根据他们发现的有趣、必要或资助开发的基础对请求进行优先级排序，因此没有整体策略或优先考虑哪些请求作为需求，并跟踪其正确实施。但是，大多数开发人员对哪些问题更重要具有一些共享的愿景，并且他们可以向发布工程团队寻求指导。
项目的验证阶段是双重的。在将代码提交给当前分支之前，开发人员请求同行审查其代码。这种审查在很大程度上是通过功能测试进行的，但代码审查也很重要。当代码提交到分支时，将进行更广泛的功能测试，这可能会触发进一步的代码审查和调试，应代码行为与预期不符。这第二种验证形式可以被视为结构验证。虽然子项目本身可以编写形式测试，如单元测试，但这些测试通常不会被主项目收集，并且通常在将代码提交到当前分支之前被删除。 ^ [9] ^
6.5. 维护
对于项目来说，最好是对源代码的每个领域都至少有一个了解该领域的人。 代码的某些部分有指定的维护者。 其他部分有事实上的维护者，系统的某些部分没有维护者。 维护者通常是来自编写和集成代码的子项目的人，或者是将其从为其编写的平台迁移过来的人。 维护者的工作是确保代码与代码所来自的项目同步，如果它是贡献的代码，那么应用社区提交的补丁或编写修复已发现的问题。
放入 FreeBSD 项目的主要工作量是维护。 [Jørgensen, 2001] 绘制了一个显示变更生命周期的图。
乔根森的变革整合模型
代码
审查
复习
预提交测试
代码
预提交测试
开发发布
代码
开发版本
并行调试
代码
并行调试
产品发布
代码
生产发布
代码
这里“开发发布”指的是-CURRENT 分支，而“生产发布”指的是-STABLE 分支。“预提交测试”是指在同事开发人员受邀进行功能测试或尝试代码以确定子项目状态时进行的测试。“并行调试”是指在-CURRENT 分支中包含代码时可以触发更多审查和调试的功能测试。
在撰写本文时，该项目有 269 位贡献者。当他们向一个分支提交更改时，这构成了一个新版本。社区中的用户通常会跟踪特定分支。新版本的立即存在使得变更立即广泛可用，并允许社区快速反馈。这也使得社区对他们重要的问题有了他们期望的响应时间。这使得社区更加投入，从而获得更多和更好的反馈，进而促进更多的维护，最终应该创造出一个更好的产品。
在对树的某些部分进行更改之前，如果该部分的历史对于提交者来说是未知的，提交者需要阅读提交日志，了解为什么某些功能实现的方式是这样的，以免犯以前已经考虑过或解决过的错误。
6.6. 问题报告
在 FreeBSD 10 之前，FreeBSD 包含一个名为 send-pr 的问题报告工具。问题包括 bug 报告、功能请求、功能增强以及通知项目中包含的外部软件的新版本。尽管 send-pr 可用，但鼓励用户和开发人员使用我们的问题报告表单提交问题。
问题报告被发送到一个电子邮件地址，然后插入到问题报告维护数据库中。Bugbuster 对问题进行分类，并将其发送到项目内的正确组或维护者。一旦有人对报告负责，报告就会被分析。这个分析包括验证问题并为问题想出解决方案。通常需要从报告发起者或甚至从 FreeBSD 社区获得反馈。一旦为问题制作了补丁，可能会要求发起者尝试。最后，工作中的补丁被集成到项目中，并在适用的情况下进行文档化。然后，它按照维护部分中描述的常规维护周期进行。问题报告可能处于以下状态之一：打开、分析、反馈、已打补丁、暂停和关闭。暂停状态是指由于缺乏信息或由于任务需要太多工作而目前没有人在处理时无法进展。
图 8. 过程摘要：问题报告
报告发起者报告问题。然后由错误修复者对问题进行分类，并交给正确的维护者。他们验证问题，并与报告发起者讨论问题，直到他们获得足够的信息来创建一个可行的补丁。然后提交此补丁，并关闭问题报告。
此过程中包括的角色有：
[ FreeBSD，2002 年 C ]。[ FreeBSD，2002 年 D ]
6.7. 对不端行为做出反应
自 2001 年起，FreeBSD 确立了一系列开发者应遵守的规则。然而，规则偶尔会被违反。以下规定旨在针对不当行为做出反应。它们明确了会导致开发者提交权限暂时中止多长时间的行为。
未经发布工程团队批准在代码冻结期间提交代码 - 2 天
在未经批准的情况下承诺到安全分支 - 2 天
提交战争 - 所有参与方需 5 天
无礼或不当行为 - 5 天
【Lehey，2002】
为了让停职生效，任何单个核心成员都可以在在“核心”邮件列表上讨论之前实施停职。在核心成员经过 2/3 的投票通过之后，惯犯可能会受到更严厉的惩罚，包括永久取消提交权限。（然而，后者总是被视为最后的选择，因为它固有地会引起争议。）所有的停职都会发布到“开发者”邮件列表上，这是一个只开放给提交者的列表。
很重要的是，您不能因为技术错误而被停职。所有的惩罚都来源于违反社交礼仪。
在这个过程中涉及到的帽子:
6.8. 发布工程
FreeBSD 项目设有一个发布工程团队，一个主要的发布工程师负责创建能够通过网络提供给用户社区或在零售店销售的 FreeBSD 版本。由于 FreeBSD 在多个平台上都可用，并且针对不同架构的发布同时可用，因此该团队每个架构都有一个负责人。此外，团队中还有负责协调质量保证工作、构建软件包集以及更新文档集的角色。在提到发布工程师时，指的是发布工程团队的代表。
当一个版本发布即将到来时，FreeBSD 项目会有所变化。制定包含功能冻结和代码冻结、发布临时版本以及最终版本的发布时间表。功能冻结意味着不允许在未经发布工程师明确同意的情况下提交新功能到分支。代码冻结意味着不允许在未经发布工程师明确同意的情况下提交代码更改（例如修复错误）。这种功能冻结和代码冻结被称为稳定阶段。在发布过程中，发布工程师有完全的权限将代码回滚到旧版本，从而“撤消”变更，如果发现这些变更不适合包含在发布中。
有三种不同类型的发布：
.0 发布是主要版本的第一个发布。这些是 CURRENT 分支的分支，由于 CURRENT 分支的不稳定性，具有显着更长的发布工程周期
.X 发布是 STABLE 分支的发布。它们计划每 4 个月发布一次。
.X.Y 发行版是遵循 .X 分支的安全发布版。只有在自上一个分支发布以来合并了足够的安全修复时才会发布。很少包含新功能，安全团队在这方面比常规发布更加参与。
对于 -STABLE- 分支的发布，发布过程在预期发布日期前的 45 天开始。在第一阶段，即前 15 天，开发人员将他们在 -CURRENT 中想要包含在发布版中的更改合并到发布分支中。当此期间结束时，代码进入为期 15 天的代码冻结阶段，在此阶段只允许进行错误修复、文档更新、与安全相关的修复和较小的设备驱动程序更改。这些更改必须事先获得发布工程师的批准。在最后 15 天期间开始时，将创建一个发布候选版供广泛测试。在此期间不太可能允许更新，除非是重要的错误修复和安全更新。在这最后阶段，所有发布都被视为发布候选版。在发布过程结束时，将创建一个带有新版本号的发布版，包括网站上的二进制发行版和 CD-ROM 镜像的创建。但是，在发送到邮件列表 freebsd-announce 的 Pretty Good Privacy 签名消息之前，发布不被视为“真正发布”；在发送 PGP 签名消息之前，任何标记为“发布”的内容可能仍在进行中，并可能在发送 PGP 签名消息之前发生变化。 ^[ 11]^。
-CURRENT-分支的发布（即以".0"结尾的所有发布）非常相似，但时间跨度是原来的两倍长。发布前 8 周开始公布发布时间表。进入发布流程两周后，启动功能冻结，性能调整应保持最低限度。发布前四周，官方的测试版发布。发布前两周，代码正式分支为新版本。该版本被赋予发布候选状态，与-STABLE 的发布工程一样，发布候选的代码冻结是加固的。然而，主开发分支上的开发可以继续。除了这些差异，发布工程流程是相似的。
.0 版本进入自己的分支，主要面向早期采用者。然后该分支经历稳定期，直到发布工程团队决定满足了稳定性要求，该分支才变为-STABLE，而-CURRENT 则针对下一个主要版本。尽管大多数情况下是.1 版本，但这并非必须。
大多数发布是在被认为距离上一个发布足够长的日期时进行的。设定每 18 个月进行一次主要发布和每 4 个月进行一次次要发布的目标。用户社区已经非常明确地表示，安全性和稳定性不能被自我设定的截止日期和目标发布日期所牺牲。为了避免时间滞后对安全性和稳定性问题造成过长影响，提交更改到-STABLE 时需要额外的纪律。
制定发布时间表
功能冻结
代码冻结
制作分支
发布候选版
稳定发布（根据需要反复执行上一步骤；当发布被认为稳定时，继续下一步）
构建软件包
警告镜像
发布版本
[FreeBSD，2002 年]
7. 工具
用于支持开发过程的主要支持工具包括 Bugzilla、Mailman 和 OpenSSH。这些是外部开发的工具，通常在开源世界中被广泛使用。
7.1. Git
Git 是处理多个文本文件版本和跟踪谁提交了什么更改以及为什么的系统。一个项目位于一个“仓库”中，不同的版本被视为不同的“分支”。
7.2. Bugzilla
Bugzilla 是一个维护数据库，由一组工具组成，用于在中央站点跟踪错误。它支持发送和处理错误的错误跟踪过程，以及查询和更新数据库和编辑错误报告。该项目使用其 Web 界面将“问题报告”发送到项目的中央 Bugzilla 服务器。提交者还拥有 Web 和命令行客户端。
7.3. 邮件列表管理程序
Mailman 是一个自动化邮件列表管理程序。FreeBSD 项目使用它来运行 16 个通用列表，60 个技术列表，4 个限制列表和 5 个包含 Git 提交日志的列表。它还用于 FreeBSD 社区中其他人和项目设置和使用的许多邮件列表。通用列表是面向公众的列表，技术列表主要用于特定兴趣领域的开发，封闭列表用于内部沟通，不面向公众。项目中大部分通信都通过这 85 个列表进行[FreeBSD，2003A，附录 C]。
7.4. 相当好的隐私保护
相当好的隐私保护，更为人熟知的是 PGP，是一种使用公钥架构的加密系统，允许人们进行数字签名和/或加密信息，以确保两方之间的安全通信。在发送信息给多个接收者时，会使用签名，这样他们可以在接收之前验证信息没有被篡改。在 FreeBSD 项目中，这是确保信息由声称撰写的人而非在传输过程中被更改的主要手段。
7.5. 安全 Shell
安全 Shell 是一种用于安全登录到远程系统并在远程系统上执行命令的标准。它允许建立和保护两个涉及系统之间的其他连接，称为隧道。这个标准有两个主要版本，只有版本二被用于 FreeBSD 项目。该标准最常见的实现是 OpenSSH，它是项目主要发行版的一部分。由于其源代码更新的频率比 FreeBSD 发行版更快，最新版本也可以在 ports 树中找到。
8. 子项目
子项目是为了减少协调开发人员组的沟通量而形成的。当一个问题领域被充分隔离时，大多数沟通将在致力于问题的小组内部进行，相较于未被隔离的组，与他们交流的沟通会更少。
8.1. Ports 子项目
一个 "port" 是一组元数据和补丁，它们需要在 FreeBSD 系统上正确获取、编译和安装外部软件。 ports 的数量以惊人的速度增长，如下图所示。
1995 年至 2022 年间新增的 ports 数量
镜像::portsstatus.svg
[fig-ports]显示了 1995 年至 2022 年间 FreeBSD 可用的 ports 数量。看起来曲线首先呈指数增长，然后从 2001 年中期到 2007 年中期以每年约 2000 个 ports 的速度线性增长，然后增长速度变慢。
由于 port 描述的外部软件经常在持续开发中，维护 ports 所需的工作量已经很大，并且正在增加。这导致 FreeBSD 项目的 ports 部分拥有更加强大的结构，并且越来越成为 FreeBSD 项目的一个子项目。
Ports 有自己的核心团队，由 Ports 经理领导，该团队可以任命提交者，无需经过 FreeBSD 核心团队的批准。与 FreeBSD 项目不同，ports 子项目包含许多活跃的维护者，他们并非提交者，因此很多维护工作并不一定会获得提交权限。
与主项目不同，ports 树没有分支。FreeBSD 的每个发布版本都遵循当前 ports 集合，因此提供了关于程序位置和构建方法的最新信息。然而，这意味着对系统有依赖的 port 可能需要根据运行的 FreeBSD 版本的不同而有所变化。
由于 ports 存储库没有分支，无法保证任何 port 能在除了-CURRENT 和-STABLE 之外的其他版本上运行，尤其是旧的次要发布版本。既没有基础设施，也没有志愿者时间来保证这一点。
为了沟通的效率，依赖于 Ports 的团队，如发布工程团队，拥有他们自己的 ports 联络人。
8.2. FreeBSD 文档项目
FreeBSD 文档项目始于 1995 年 1 月。从最初的一个项目负责人、四名团队领导和 16 名成员，现在他们一共有 44 名提交者。文档邮件列表的成员数刚好不到 300 人，表明围绕它有一个相当大的社区。
文档项目的目标是为 FreeBSD 项目提供良好且有用的文档，从而使新用户更容易熟悉该系统，并为用户详细介绍高级功能。
文档项目的主要任务是在“FreeBSD 文档集”中处理当前项目，并将文档翻译成其他语言。
像 FreeBSD 项目一样，文档也分为相同的分支。这样做是为了保持每个版本的文档始终更新。只有文档错误才在安全分支中得到纠正。
像 ports 子项目一样，文档项目可以在没有 FreeBSD 核心批准的情况下任命文档委员。[ FreeBSD，2003B]。
文档项目有一个入门指南。这既用于向新项目成员介绍标准工具和语法，也用作在项目上工作时的参考。
参考资料
[布鲁克斯，1995]弗雷德里克 P.布鲁克斯。版权 ©1975 年，1995 年皮尔逊教育有限公司。0201835959。Addison-Wesley Pub Co.神话般的人月。软件工程专题(第二版)。
[Saers，2003]尼克拉斯·萨尔斯。版权 ©2003 年。FreeBSD 项目的项目模型。科学学位论文。http://niklas.saers.com/thesis。
[Jørgensen，2001]Niels Jørgensen。版权 ©2001 年。把一切都放在后备箱里。FreeBSD 开源项目中的增量软件开发。http://www.dat.ruc.dk/~nielsj/research/papers/freebsd.pdf。
[PMI，2000] 项目管理学会。版权所有 ©1996 年，2000 年项目管理学会。1-880410-23-0。项目管理学会。美国宾夕法尼亚纽镇。PMBOK 指南。项目管理知识体系指南，2000 年版。
[FreeBSD，2000A] 版权所有 ©2002 年 FreeBSD 项目。核心章程。https://www.freebsd.org/internal/bylaws/。
[FreeBSD，2002A] 版权所有 ©2002 年 FreeBSD 文档项目。FreeBSD 开发者手册。开发者手册。
[FreeBSD, 2002B] 版权 © 2002 FreeBSD 项目. 核心团队选举 2002. http://election.uk.freebsd.org/candidates.html.
[FreeBSD, 2002C] Dag-Erling Smørgrav 和 Hiten Pandya. 版权 © 2002 FreeBSD 文档项目. FreeBSD 文档项目. 问题报告处理指南. 问题报告处理指南.
[FreeBSD, 2002D] Dag-Erling Smørgrav. 版权 © 2002 FreeBSD 文档项目. FreeBSD 文档项目. 编写 FreeBSD 问题报告. 编写 FreeBSD 问题报告.
[FreeBSD，2001] 版权 © 2001 年 FreeBSD 文档项目。FreeBSD 文档项目。Committer 指南。Committers 指南。
[FreeBSD，2002E] Murray Stokely。版权 © 2002 年 FreeBSD 文档项目。FreeBSD 文档项目。FreeBSD 发布工程。FreeBSD 发布工程。
[FreeBSD，2003A] FreeBSD 文档项目。FreeBSD 手册。FreeBSD 手册。
[FreeBSD, 2002F] 版权 © 2002 FreeBSD 文档项目。FreeBSD 文档项目。FreeBSD 的贡献者。FreeBSD 的贡献者。
[FreeBSD, 2002G] 版权 © 2002 FreeBSD 项目。FreeBSD 项目。核心团队选举 2002。http://election.uk.freebsd.org。
[FreeBSD, 2002H] 版权 © 2002 FreeBSD 项目。FreeBSD 项目。Commit 权限过期政策。2002/04/06 15:35:30。https://www.freebsd.org/internal/expire-bits/。
[FreeBSD，2002I] 版权所有 © 2002 FreeBSD 项目。FreeBSD 项目。新帐户创建流程。2002/08/19 17:11:27。https://www.freebsd.org/internal/new-account/。
[FreeBSD，2003B] 版权所有 © 2002 FreeBSD 文档项目。FreeBSD 文档项目。FreeBSD DocEng 团队宪章。2003/03/16 12:17。https://www.freebsd.org/internal/doceng/。
[Lehey，2002] Greg Lehey。版权所有 © 2002 Greg Lehey。Greg Lehey。在战壕中度过的两年。软件项目的演变。http://www.lemis.com/grog/In-the-trenches.pdf。
这与布鲁克斯定律相辅相成，即向一个已经延迟的项目添加另一个人会使项目变得更晚，因为这将增加沟通需求。项目模型是一种减少沟通需求的工具。
统计数据是通过计算截至 2005 年 4 月 1 日通过 portsdb 获取的文件中条目的数量而生成的。portsdb 是 port sysutils/portupgrade 的一部分。
为了找到这个数字，研究了 2004 年 1 月 1 日至 2004 年 12 月 31 日的时期。
例如，蓝牙堆栈的开发始于一个子项目，直到被认为足够稳定，才合并到 -CURRENT 分支中。现在它是 FreeBSD 核心系统的一部分。
根据 Kirk McKusick 的说法，在开发 UNIX 操作系统 20 年后，接口在很大程度上已经确定。因此，没有太多设计的必要。然而，系统的新应用和新硬件导致一些实现比过去更有益。一个例子是引入了网络浏览，使正常的 TCP/IP 连接成为短时间内的数据突发，而不是在较长时间内的稳定流。
这实际上发生的第一个版本是 4.5-RELEASE，但同时也为 4.3-RELEASE 和 4.4-RELEASE 创建了安全分支。
有一个术语上的重叠，涉及到“稳定”一词，这导致了一些混淆。-STABLE 分支仍然是一个开发分支，其目标是对大多数人有用。如果一个系统接受不能在部署时宣布的更改，则应该运行一个安全分支。
第一次核心选举在 2000 年 9 月举行
当构建系统（make world）时会执行越来越多的测试。然而，这些测试是一个非常新的补充，尚未为这些测试创建系统框架。
sendmail 和 named 是已合并自其他平台的代码的示例。
许多商业供应商使用这些镜像创建光盘，这些光盘在零售店销售。
最后更新于
