delphij's Chaos

选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……

21 Nov 2006

老大们开始讨论FreeBSD的RELENG_7是否要提前的问题了

在距离6.2-RELEASE发布还有大约一个月的时候,FreeBSD的developers邮件列表中开始了关于RELENG_7的讨论。出于对邮件列表相关规定的尊重,我不便公开这些讨论的内容,只说说一些我自己的想法。

在一个有数百人参加的开源项目中,如何保持良好的发行版本品质,同时又不伤害人们的参与热情和新功能的开发进度?

这是一个很明显的问题。对于用户来说,他们最关心的是稳定性和性能。一般说来,用户通常会对操作系统进行裁剪,以便适应他们的需要。然而,并不是所有的变动都能够有效地局部化或模块化,许多变动可能是涉及面非常广的,而另一些变动则可能涉及大量用户,或属于操作系统中「不可或缺」的部分。

许多FreeBSD的开发人员是利用业余时间进行开发活动的。多分支开发对于开发人员来说是一件很头疼的事情。许多开发人员可能没有时间和精力去维护多个分支(搭建测试环境等等都是相当耗时的工作;此外,为了维持ABI/API稳定,还需要编写一些额外的代码),因此,多数开发人员会希望只有1个STABLE分支。

据我所知,FreeBSD是所有开源项目中对分支的运用最为「彻底」的一个。从CURRENT到STABLE到Release Engineering到发布,再到后期维护,有一系列完整的流程和开发常识支持。

不过目前这个流程也存在一些问题。从开发人员的观点看,我们希望在时间精力允许的前提下更快更多地发行release版本;而从用户的观点看,他们并不希望过快地发行新版本——变动可能引入问题,等等。因此,在5-STABLE到6-STABLE的转换过程中,许多人提出了我们应制定以时间为准绳的发布计划,并停止发布「新技术release」。

从用户的观点看,这样做是很有道理的。持续可用的平稳升级,对于用户与开发团队的良性互动十分重要。另一方面,FreeBSD的三个以时间为计划依据的版本系列——2.x、4.x和6.x版本,较之3.x和5.x版本来说,都要更为成功。

不过这样一来也会带来一些问题。新功能总要有人去做「小白鼠」。多数src committer,包括一些ports和doc committer都会使用-CURRENT作为桌面系统,以便在用户之前发现新版本中引入的问题;很明显,仅仅开发人员去跑测试是不够的。操作系统不是一个计算1+1=2的应用程序,FreeBSD仅内核部分的代码就超过300万行,由于手中缺少必要的硬件、偶然的疏忽或考虑不周等等,都可能使某些变动成为「按下葫芦浮起瓢」的事故。

自行编译和运行-CURRENT是一件十分辛苦的工作,对于不了解操作系统开发和内部运行机制的用户来说更是如此。然而,我们有很多十分热情的用户,他们希望能够帮助我们进行一些这方面的工作。为此,目前每个月re@都会发布一版新的snapshot来给大家试用。

那么,话说回来,为什么会有人提议尽早划出RELENG_7呢?

主要的好处是,这样一来,-CURRENT又回归到一个可以在上面增加还不算很靠谱的代码的地方了。与此同时,-STABLE分支则可以专注于可靠性的改良。

我个人不太赞成提前7个月划RELENG_7。但明年2、3月份也许是一个比较好的时机。