1.3 Apache开发流程

1.3  Apache开发流程

Apache的开发流程既可以是自上而下的，也可以是自下而上的。采用自上而下的设计方法时，可以增加一些很棒的想法，如需要代码重写或者新的组件所带来的关键新特性、新功能，这些想法可能需要几个月甚至几年才能从概念变为成熟产品。而采用自下而上的设计方法时，可以增加一些小的补丁，用来修改一些软件Bug或者增加一些新的特性，这些小的补丁很容易融合到目前的软件版本中。

模块式开发方法通常介于软件开发的宏观方法和微观方法之间。模块是一个自包含的插件，通常是开发者（大多数情况下是其他人）基于某种兴趣而实现的新特性。一个模块可能实现了Web服务器的核心功能，也可能实现了一个通用的服务，还可能实现了一个较小但是较为重要的功能，甚至只是一个单一目的的应用。如果某个模块实现了大家都比较感兴趣的功能，而且作者愿意公布，就可以集成到Apache的核心发布版本中。但是，如果该模块需要额外的支持（如第三方的库），或者可能会涉及该模块的许可甚至是知识产权的因素，那么，该模块可能就不会被集成到Apache的核心发布版本中，而是通过它的开发者或者第三方独立地发布，就像支持Apache的公司或者Linux版本的发行商那么做。

1.3.1  Apache代码仓库

和其他的软件项目一样，Apache也维护着一个代码仓库。这个代码仓库以项目为单位，和Web服务器相关的是httpd项目（包括代码、文档和编译文件）和apr项目。

1.3.1.1  Subversion

所有的Apache代码都保存在代码仓库中，可以通过http://svn.apache.org/进行访问。代码使用SVN 进行管理，它是最近（2004年）开始使用的，之前我们使用的是和其功能类似、历史悠久的CVS系统。

代码仓库的读取权限是公开的，但是写权限只有提交者才拥有。读权限允许任何人查看Apache开发过程中所走过的足迹，包括回顾任何单一或者累计的修改，针对这些修改所作的简要的解释（例如修改Bug、新的功能、内部改进等），以及修改的日期和参与修改的人员。

1.3.1.2  分支：主线、开发版本和稳定版本

代码仓库中包含一个主线和几个分支，其中的任何文件的默认版本都是主线。在Apache项目中，主线代表正在进行中的工作。从定义上可以看出，它是未经过测试的版本，一般都包括一些实验性的代码。

Apache当前的稳定分支是Apache httpd 2.2，可以在/branches/2.2.x/目录下找到。比较老的版本（如2.0和1.3）尽管已经不再是主要的开发方向，但是它们的分支还在维护中（尽管是精简地维护）。

有时候也会为一些实验代码特别地创建一些分支，作为测试的基础。例如，当Apache2.2处于beta版测试时，为了支持异步I/O，需要对内核代码进行一些实质性的重写。这些修改后的代码对于主线来说过于实验化，因此，开发者决定创建一个新的开发分支来处理它们。这个新的分支随后逐渐地稳定下来并融入到主线中，并最终被包含在下一个稳定版本（2.4版）中。

1.3.1.3  审查和通过

Apache的开发人员针对稳定版本和开发版本的代码采用不同的开发策略进行处理。

·稳定版本的代码总是遵从审阅并提交的方式（Review-Then-Commit，RTC），这就意味着任何将要加入到标记为稳定版本分支的代码，即使是最微不足道的补丁，也必须通过一个严格的审阅过程。

·开发版本的代码遵从提交并审阅的方式（Commit-Then-Review，CTR），这就意味着代码可能被某个提交者单方面地进行了增加、修改和删除，然后在恰当的时期由其他开发者进行审阅（当然，SVN使得对某个改变进行逆向操作变得非常容易）。不过，一些主要的变动需要在提交之前就进行审阅，或者使用单独的开发分支进行处理。

1.3.1.4  增加新的功能（backport）

新的代码首先加入主线。如果某个开发人员想让这个代码成为稳定分支的一部分（通常是修改了Bug或是做了一点改进），那么这个代码就将进入backporting阶段。该阶段使用一个叫做STATUS的状态文件，包含了backporting的当前情况列表，如为backport进行的投票情况等。

为了保证backporting的质量，代码的任何变动必须从提交者那里得到至少三张支持票。一张支持票意味着投票人已经审阅了这个变动，并对此表示认可，因此，三张支持票就明确意味着这个变动确实不错。即使是最简单的Bug修改也要遵守这个规则，这就是说为了得到足够多提交者的同意，有时候一个不是很重要的Bug修改也得需要很长时间。如果收到了三张支持票并且没有反对票，这个变动就可以加入到下一个稳定分支中了。

可能审阅了这个变动的提交者对此并不满意，他将对此保留意见，甚至投反对票。投反对票的规则是必须附带一个说明，以及（或者）一个能够实现该变动目标的可选方案。被投了反对票的变动要么被放弃了，要么把其中的错误修正之后再次提交进行重新投票。反对票和保留意见通常会在开发者论坛中进行相关的讨论之后被进行处理。

1.3.1.5  发布

Apache有时会发布新的版本。当前稳定代码版本（在本书正在写作时为2.2.x版）的发布使得用户可以感受到Apache的最新进展，也修改了一些Bug。这些发布版本将会打上最佳版本的标签并推荐给用户。通常由于开发者觉得已经有足够多的小变动积聚起来了，达到了新版本发布的要求，这样一个新的版本就发布了。不过有时候一个新的版本可能是因为某个安全问题引起开发者的注意而匆忙发布的。发布负责人通常由开发者志愿担任，负责管理发布流程并创建发布版本，其他的开发者将会全神贯注于开发在STATUS文件中已经核准的、但还没有解决的更新，并将其融入到稳定版本中。

目前的策略是偶数版本的分支是稳定的，而奇数版本的分支打算供开发使用 。因此2.0.x版本（2002年4月发布）和2.2.x版本都是稳定的，而2.1.x发布版供Apache2.2版本的alpha测试和beta测试使用。Apache2.1版本经过接近10个月的alpha测试和3个月的beta测试之后才成为最终的2.2稳定版本。

一个发布版需要在每一个支持的平台上经过编译、安装、运行的测试。这些步骤对于稳定的发布版本来说是必需的。对于开发版本，尽管不是那么严格，也是应当如此。为了保证发布版本满足这些要求，发布负责人首先通过一个合适的SVN分支为这个版本创建一个Build版本，然后把这个版本告知Apache的开发者和测试者。这就在其发布之前提供足够的时间，让更多的开发者和测试者对其在不同的硬件环境、操作系统和应用环境上进行安装和测试。如果在测试中发现了一个严重问题，那么这个Build版将不被发布。

所有的发布版本都由发布管理人进行可靠的PGP签名。很多Apache开发者的公钥，包括所有发布管理人的，都可以在http://www.apache.org/dist/httpd/KEYS获得。

1.3.2  开发者论坛

Apache Web服务器最主要的开发者论坛就是dev@httpd.apache.org邮件列表。所有和Apache开发相关的技术细节都在这里讨论。一个与此类似的开发者邮件列表dev@apr.apache.org是针对APR开发的。这些论坛都是100%对外开放的，所有的讨论都被归档在一些地方（本章结尾部分的参考地址）。
另外一个比较流行的开发者论坛是互联网中继聊天（Internet Relay Chat，IRC）。关于Apache的开发者频道是irc.freenode.net上的#httpd-dev和#apr。这些讨论地点都是完全对外开放的。

在http://issues.apache.org/ 的Apache Bugzilla是一个可以搜索的数据库，包括Bug报告、提升要求和补丁，也包括目前的和历史的数据。这个数据库也是完全对外开放的。不过要注意的是，既然是一个完全开放的数据库，它会含有很多的虚假报告（有些由于不能被结束而显示为“再次开放”）和不能被验证真伪的报告。考虑到某些补丁可能对用户有用，但是这些补丁却没有被标准的Apache发布版包括进来，因此这个数据库也包含了一些故意保留下来的、标记为“补丁可获取”（PatchAvailable）的报告。

包含所有代码和变动的最完整、最精确的归档是位于http://svn.apache.org/的Subversion代码仓库。这个代码仓库随着代码的变化而实时地被更新。读权限是开放和公开的，而写权限只授予认证过的提交者。在Subversion中值得注意的是STATUS文件和CHANGES文件，前者包括了目前的讨论和投票情况，而后者则提供了针对某个稳定/发布版本的变动的执行总结。

1.3.3  开发人员

Apache很重要的一个特点就是用户群体的多样性和开发群体的多样性。Apache项目不存在由某个公司或者某些公司主导的问题。有些开发者（包括作者在内）既是一个自由职业的顾问，也是一个小公司的员工。其他的开发者有些来自像IBM、Red Hat和Novell这样的大公司，有些来自像Google、Yahoo!和Ask Jeeves这样的大型客户，也有些来自科研院校和其他的非商业组织。虽然大部分开发者都是企业的员工，但是自由职业者的数量超过了任何一个公司的人数。

更为重要的是，开发者的多样性反映了Apache广泛的应用范围。那些超级繁忙的站点（如CNN和HEAnet）需要用24×7的时间承担成千上万的并发用户负载，主要关注性能、扩展性和稳定性；而某些应用站点，例如作者的网站Valet，主要关注如何把Apache从它最初的Web服务器的角色拓展为应用服务器；电子商务网站主要关注安全性和可靠性；主机托管公司需要在维护安全和稳定的同时支持需求差异巨大的用户和代理控制。拥有数量众多来自各行各业的、活跃的开发者，使得Apache在所有这些应用环境下都能工作得很好。

最后，Apache开发者社区决不是一个排外的黑客社区。尽管软件开发和维护是Apache开发者所有活动中最重要的，但仍然有人在没有写过一行C语言代码的情况下被提拔到Apache组织的高层，因为技术支持、文档编写和行政等工作与开发工作一样重要。

1.3.4  参与Apache工作

所有的社区论坛都是对公众开放的，这里欢迎任何一个想为Apache贡献力量的人。有很多种方式可以加入Apache，而每一种工作都很有意义。

·动手编码。欢迎为Bugzilla提出的Bug提供补丁。开发者可在列表上正在争论的主题或者在STATUS文件中突出强调的主题做出贡献。如果某位开发者想加入工作，可以到位于SVN的代码仓库中搜索TODO记录和FIXME记录。如果一个补丁能够干净地集成（通过diff –u或者svn –diff方式），并且有比较清晰的动机和功能描述，那么这个补丁是受欢迎的。补丁便可以通过开发者列表或Bugzilla发布。

·撰写文档。文档存放在SVN中。所有的原始文档都是XML格式的，该格式是DocBook的一个子集。欢迎撰写新的文档，或者对原有的文档进行修订（添加补丁）。

·文档翻译。文档一般都具有多个语言的版本。但不是文档中每一页都具有不同语言的版本，而且文档的翻译版本也不一定都是最新的。因此如果你具有语言天赋，那么就去找到缺失的或者过时的文档并修正它们吧。

·测试软件。在你的平台上构建并测试代码，特别是当你具有一个与众不同的平台时。使用不寻常的环境和工具构建Apache，它能够干净地构建和安装吗？可以使用你所有不寻常的任务对它进行压力测试。如果它失败了，或者你发现它相对于之前的版本有一个意想不到的变化，试着去诊断究竟发生了什么。把你找到的任何Bug都通过开发者列表和Bugzilla报告出来。努力保证你所描述的情况是清晰明了并且可重现的。

·构建软件。维护Apache的构建和安装是一个很重要的任务，但是直到本书写作为止我们都没有很好地处理它。即使是在UNIX/Linux家族平台上最广泛使用的GNU基于自动配置的安装，检查一下都是有好处的。