我这次不铁口直断了，估计明年见了，如果这周能够RC2的话，最终RELEASE估计要到明年的1月5日左右。

这次FreeBSD 7.1在软件工程角度是相当失败的案例，我想我们应该从里面总结一些教训出来。

首先，我们的目标是什么？

我想，用户对于一个发行版本的期待是：一个经过了大量测试的、阶段性的稳定版本。而开发人员对于发行版本的期待则是尽可能地将可用的功能交付给用户。作为OS，我认为这应该包括自动化的回归测试、性能改进、更新的驱动程序、文档的修订，以及更新的第三方软件等等。

FreeBSD目前的开发模式，是将分别开发的三大模块，即内核与基本系统(src/)、文档(doc/)、第三方软件(ports/)的人在一定的时候聚集在一起，通过代码冻结的方法来使他们从增加新功能转移到集中去修bug，最后发布一个版本。这个模式在过去运转的相当好，以至于我们没有发现其中存在的问题。

这次FreeBSD 7.1暴露出来了这个模式存在的很多问题。例如，由于安全小组发现了很多安全漏洞，而另一方面，安全小组的人手不够，限制了修正这些问题的速度。我本人撰写的一个安全公告等了一个月才在今天最终公之于众，而另一方面，安全小组对于发行版本拥有一票否决的绝对权力，导致6.4和7.1的发布都一再推迟。

而作为非常快节奏的开发的 ports/ 维护者，则对不断的推迟感到相当不满。FreeBSD目前只维护 ports/ 的 -HEAD，也就是说，在正式发行 -RELEASE 之前，ports/ 不能进行大量的、破坏性的修改。例如，我本人维护的 OpenLDAP 现在就必须等待 -RELEASE 之后才可以进行升级。不断地推迟新的发行版本，会导致 ports/ 的开发继续延迟。

多种因素作用在一起的结果是，这次7.1-RELEASE的发布让所有的人都不太满意。

我想，想要解决这些问题，需要从几个方面入手。

首先是功能冻结和代码冻结的时间。目前，FreeBSD的做法是src/和ports/几乎同时开始冻结，但是实际上 src/ 需要花费的测试周期要比 ports/ 多。举例来说，一次正常的 -STABLE 发行版本所需要的测试和除错周期大约是 8 - 10 周，而完成一次 ports/ 联编所需要的时间则只需要 48 － 160 小时，并且这个过程是持续进行的。我认为我们必须定义一个功能冻结点，这个点之后，不再允许在 -STABLE 分支中增加任何新的API/ABI，然后以这个版本（例如-RC1）为基础进行 ports/ 的联编。另一方面， ports/ 是否有必要随 src/ 冻结？我认为意义不大，因为多数用户并不会使用光盘附带的 package，甚至于使用 -STABLE 的 package 会成为阻碍在 -STABLE 分支中增加新的 API 的障碍，这样一来，在人手有限的情况下，人力不如去维护一个每季度创建一次的稳定 ports/ 分支（只升级其中的安全更新；只维护最多两个分支；确定交付时间），而 -RELEASE 则随同最近的一个这样的分支去发布。

在升级支持方面，目前FreeBSD发布新版本的周期显得过长。这会带来两个问题：其一，在无法预测何时会发布发行版本的前提下，用户如何安排升级？其二，在这样一段较长的时间内，如果出现新的硬件，发行版本光盘无法及时更新，而普通用户更新光盘中的驱动程序则比较困难。

为了因应这种情况，我认为我们应该将现有的 X.Y 发行版模式改为 X.Y.Z 发行版模式。其中，X每18个月发布一个新版本，Y每6个月发布一个新版本，而Z的发行周期则视需要而定，每一个新的Z版本均发布对应的ISO文件，而其中除了重要的安全和可靠性更新之外，也包含经过较长测试的、对于新硬件的支持改进，作为对 -STABLE 快照的补充。

最后的问题其实还是，我们的发行版本的目标用户人群是什么？我希望能够得到一些来自用户的反馈。还有一个好消息是，这个礼拜我们总算有希望能看到RC2了……