FreeBSD 本月动态
作者：Dru Lavigne
作为成熟的开源项目，FreeBSD 项目拥有定义明确、文档完善的发布管理流程，以及发布工程团队和首席发布工程师。本月，我们有机会采访 Glen Barber，他自 2013 年 1 月起加入 FreeBSD 发布工程团队，自 2014 年 3 月起担任首席发布工程师。
问： 请介绍一下你自己。你的技术背景是什么？你是如何开始使用 FreeBSD 的？
答： 我今年 33 岁，住在美国宾夕法尼亚州。我大约从 2006 年开始使用 FreeBSD，之前在一本 Linux 杂志上读到了相关文章。我记得坐在医生诊所的候诊室里，偶然看到一篇关于这个叫 FreeBSD 的东西的小文章，当时它刚发布 6.1-RC1。我把那页折了个角，提醒自己回家后试试 FreeBSD，主要是因为我想给 Dell Inspiron b120 笔记本换个不同的操作系统。
那时我刚恢复上大学。我在笔记本上用 Linux 可能有一两年了，因为很容易找到不同的软件和工具。那时我完全不知道自己想做什么职业，但我知道自己想和计算机打交道。也是在这时我第一次接触到开源软件，开始发现所有那些优秀的项目和社区。
所以看完病回家后，我下载了 6.1-RC1 安装程序，在一台备用的台式机上安装了我的第一个 FreeBSD 系统。FreeBSD 有很多我喜欢的地方（也有一些不喜欢的），但总体来说，它给我的感觉就是对了。我特别喜欢基本系统和第三方软件之间的分离，这正是我不喜欢 Linux 的地方——每个发行版都有自己不同的“基本安装”方式，当然也用不同的工具。只需运行几条命令就能得到一个干净的基本安装，这是 FreeBSD 最吸引我的地方之一。
等我对 FreeBSD 足够熟悉后，我用 6.1-RELEASE 替换了笔记本上的 Linux，从那以后，我拥有的每一台电脑（笔记本、台式机和服务器）都是 FreeBSD 系统。回想起来，我常常对那几乎是偶然的一连串事件感到好笑，正是这些事件让我走进了 FreeBSD 的世界，尤其是考虑到我后来在项目中的角色。
问： 大多数读者应该已经对发布工程流程有所了解。发布工程师的典型工作日是什么样的？随着发布日期临近，工作日如何变化？
答： FreeBSD 的发布周期实际上在任何公开可见的变化（如代码冻结或候选发布版构建）出现之前的几个月就开始了。
最近，我们尝试在周期开始前三个月就在发布工程团队内编写并商定下个发布的日程，之后会向 FreeBSD 开发者发送几封提醒邮件。
这看起来微不足道，但尽早与 FreeBSD 开发者沟通目标日期非常重要，因为我们通常会收到一些回复，告知正在进行中、计划纳入本次发布的工作，例如新功能或重要的 bug 修复。有时我们会授予开发者全面批准，这样在代码冻结期间每项变更无需预先批准。是否授予全面批准取决于几个因素，比如目标变更的规模和预期变更的自包含程度。例如，新网络设备驱动可能是授予全面批准的候选，而虚拟内存子系统的大规模重构则不会。
为一个操作系统发布编写日程比想象中要复杂得多，因为有那么多不同的部分需要协调、需要完美配合才能让一切拼到一起。例如，我们要确保为发布构建好二进制包，而这必须等到接近发布周期末尾才能进行。FreeBSD 文档项目的源码需要为发布打标签，这样文档包才能用于发布，而这必须在包构建之前完成。自从 FreeBSD Ports 开始按季度分支以来，将包构建与季度分支对齐也很有意义，因为季度分支也是发布标签的基础。
然后，发布周期的每个阶段（如 BETA 和 RC 构建）都需要正确把握时机。对于 10.1-RELEASE，每个 BETA 和 RC 构建（从开始到完成所有支持的架构）大约需要九小时。如果构建过程中出了问题（人为错误或构建过程中的 bug），就要从头开始重构建。然后还需要大约八小时让镜像同步到 FTP 镜像。接着需要留出足够的时间供发布工程师和 FreeBSD 用户测试，以及在下一轮构建开始前足够的时间修复 bug。这一切在编写日程时都需要提前数月考虑，正如你所见，很容易落后于日程。它复杂得出奇，真的有点像在拼一幅拼图。
代码冻结一开始，事情就会迅速加速。代码冻结期间的每次变更都需要发布工程团队成员的明确审查和批准，除非已授予全面批准。发布周期中会有大量邮件，幸运的是发布工程团队中有许多活跃的 FreeBSD 开发者，所以审查/批准流程的周转时间很短。根据具体变更，我们偶尔会请教发布工程团队中对系统该部分有专长的人，或请求团队外的人审查，这可能会延迟批准请求的回复，但通常不会延迟太多。
在 BETA 或 RC 构建开始前约一天，我会给发布工程团队发邮件，通知构建将按计划开始，任何提交批准请求在构建完成并测试之前不应答复。我也会给 FreeBSD 开发者发类似的邮件，告知他们的批准请求将在构建完成后答复，以免开发者以为请求没收到。
最近，我一直尝试在 00:00 UTC 左右开始构建，但这并不是我们工作流程或政策的既定部分。主要原因是构建所需的时间，以及构建完成顺序决定的时机。自 FreeBSD 9.2-RELEASE 起，非 x86 架构的发布构建在 amd64 硬件上交叉构建，这让完成顺序可预测。构建在 00:00 UTC 左右（当地时间约 20:00）开始后，我可以相当确定 FreeBSD/amd64 和 FreeBSD/i386 构建会在午夜左右完成，之后我将安装介质复制到本地测试机器。这通常要花几小时，所以剩下的构建串行执行、x86 构建在本地完成复制时，我能睡上几小时。
当然，这是假设没有出问题。出问题时必须处理。问题可能各不相同，不一定表示 FreeBSD 源码树有问题。也有人为因素。不止一次（次数比我愿意承认的多），我不得不重启 BETA、RC，甚至最终的 RELEASE 构建，因为我自己犯了错误。这些错误可能是在构建所用的 release.conf 配置文件中为源码树设置了错误的 Subversion revision，也可能是配置文件中一个细微的拼写错误。错误难免会发生，只要发生，就意味着一个不眠之夜。
构建完成后，我将安装镜像复制到公共 Web 服务器，并给 FreeBSD 发布工程团队和 FreeBSD 安全团队发送 PGP 签名邮件，提供镜像的 URL，让发布工程团队其他人可以下载并协助测试。安全团队随后开始为 freebsd-update(8) 用户构建各种补丁集。
镜像测试通过后，会上传到主 FTP 镜像，等待传播到全球各镜像。然后我会给发布工程师和安全团队发邮件，告知大约何时会向邮件列表发送公告邮件。公告邮件发出后，我们开始处理自构建开始以来积压的提交批准请求，并密切关注邮件列表和问题报告系统，留意可能出现的问题。
任何一次 FreeBSD 发布的演进都很有意思，因为涉及的因素太多了。发布周期开始时，提交批准请求的流入相当稳定，但随着我们走过发布周期的各个阶段，对允许变更的把关越来越严格。反过来，随着周期推进、BETA 和 RC 构建发布，下一版本的采用似乎在缓慢但稳定地增长。
我应该说明，除了我自己对发布周期阶段和问题报告的观察之外，我们没有确凿证据支持这一点。越接近发布周期末尾，我们对批准哪些变更请求就越谨慎。这在周期末尾尤其棘手，因为我们确实想修复发布中未解决的问题，但也总有引入回归的风险，这可能让发布周期的最后几周压力很大。
举个例子，假设有一个关于磁盘控制器驱动的问题报告：每 300 次写入就有一次向磁盘写入垃圾数据。这是一个严重的问题，当然是非常不可取的行为。作为 FreeBSD 发布工程师，解决方案远不是“修一下就行”那么简单，尤其是当我们已经宣布了按日程是最终候选发布版的时候。在周期的那个阶段，每个方案都不理想。
驱动更新意味着要在日程中再加一个候选发布版。但如果修复不像驱动更新那么简单呢？如果修复需要更新 cam(4) 子系统呢？修复会不会对使用 cam(4) 的其他驱动产生不良影响？我们甚至确定问题不是硬件故障、根本不是 bug 吗？这些都是需要回答的问题，每个答案都在“我们该怎么办？”这个艰难决策中扮演重要角色。
问： 发布正式发布前需要完成的清单有哪些？
答： 除了前面提到的准备发布日程时事件顺序的安排，最需要做的事是测试。这听起来是显而易见的答案，但有些事情在前置阶段完成之前无法测试，所以发布周期的每个阶段可能略有不同。
例如，BETA1 构建完成后，我会把注意力集中在安装器和基本系统中其他“安装”类软件上。如果 bsdinstall.8 中发现严重问题，可能会迅速改变我在 BETA2 上的关注点。我的主要测试环境是一台相对现代、性能强劲的机器，磁盘空间充裕（目前有 4.2 TB 可用空间），运行 FreeBSD-CURRENT。我用 VirtualBox 测试安装镜像和已安装的系统，因为可以用脚本创建不同配置的机器。
我从三台预配置的虚拟机开始，一台用于 FreeBSD/amd64，一台用于 FreeBSD/i386，最近又在其中加了一台用于 FreeBSD/amd64 UEFI。我拿这些已配置好虚拟硬盘、内存和虚拟 CPU 的机器，针对各种不同安装路径克隆。我会创建一台“FreeBSD amd64 bootonly”虚拟机来启动测试 bootonly.iso 镜像，但由于分发集尚未出现在 FTP 镜像上，这些镜像一旦验证可启动，我也做不了更多。我们不会在测试通过之前把镜像发布到 FTP 镜像，以防发现需要重构建的严重问题——那样从镜像站点撤回有问题的构建会更麻烦。
对于 disc1.iso 安装镜像，我创建四台独立的虚拟机。一台用于测试安装，所有选项使用默认值；一台用于测试 root-on-ZFS 安装；一台用于测试带 GELI 加密磁盘的 root-on-ZFS；最后一台是第一台的克隆。安装完成后，我在第一台虚拟机上安装 GNOME 桌面，第二台上安装 KDE，并做基本测试。由于最终包集还远未就绪，考虑到 Ports 树变化之快，现在花太多时间深入测试桌面机器没有意义。今天不能用的明天可能就能用了，反之亦然。
然后我为 dvd.iso 安装镜像创建两台虚拟机，一台装 GNOME，一台装 KDE。由于我已经用 disc1.iso 测试过安装路径，这时不需要在安装器上花太多时间，可以集中精力测试 DVD 自带包的安装。
当发布周期下一阶段的 BETA2 构建就绪时，我用 subversion 日志中的变更列表作为测试重点。假设自 BETA1 以来安装器没有变化，我可以少关注各种安装路径的细节，把更多时间花在测试自 BETA1 以来变更的内容上（在硬件条件允许的范围内尽可能多测）。
第一个候选发布版就绪后，FreeBSD Ports 管理团队就可以为发布构建包了。需要注意的是：如果包构建完成后 FreeBSD 的 ABI（应用二进制接口）或 API（应用编程接口）发生变化，就必须重新构建。不幸的是，这种情况确实会发生。
我们一般在 RC2 阶段就有最终包集可用，那时我开始把测试重点更多地放在系统使用上，比如测试 GNOME 和 KDE 的各个部分。我还会安装 Apache、Nginx 和 PostgreSQL 等服务器软件，确保没有明显的问题。
我认为这样测试的好处是，我在发布周期末尾可以少操心安装问题，把注意力集中在预期即将发布的操作系统上。
问： 发布工程师执行的任务只是一个庞大项目的一部分。发布工程团队还和谁合作？
答： 我们与 FreeBSD 开发者密切合作，主要通过审查/批准流程，以及与 Ports 管理和文档工程团队协调各源码树打标签和包构建。
不过，要说合作最密切的，还是 FreeBSD 安全团队，原因有很多。FreeBSD 安全官和副安全官是仅有的能访问 freebsd-update(8) 构建机的两人，所以在 BETA 和 RC 阶段我们需要保持沟通渠道畅通。发布工程团队和安全团队在流程的其他环节也需要同步，比如确定发布的生命周期终止日期，以及发布后跟进未解决的勘误项。
问： 你担任首席发布工程师将近一年了。你学到了什么？过程中有什么意外吗？
答： 这绝对是一次学习经历。我确实体会到了担任发布工程师这份工作有多难。我对所有 FreeBSD 发布工程师的敬意和感激，怎么表达都不为过。
为一个操作系统做发布工程师很艰难，可能无法和任何其他软件项目相比。需要说明的是，我完全不是说其他软件项目不如操作系统重要。但发布操作系统时，确实有很大的灾难风险。毫无疑问，这是我做过的最难的工作。它也是我做过的最有回报的工作，是一段与众不同的经历。这也是我真心感激 FreeBSD 开发者和 FreeBSD 社区的原因之一。FreeBSD 项目里有了不起的人。
你可以在 https://www.freebsd.org/releng/ 了解更多关于 FreeBSD 发布工程团队及其发布工程流程的信息。
Dru Lavigne 是 FreeBSD 基金会董事，BSD 认证小组主席。
最后更新于