LA NAVE DESPEGA CAMBIO

Like any other software project, Apache maintains a codebase. This codebase is divided into projects; those relevant to the webserver are httpd (which includes

code, documentation, and build files) and apr.

1.3.1.1 Subversion

All Apache code is kept in a repository at http://svn.apache.org/. The code is

managed by Subversion (SVN),1 _{a modern revision-control system suitable for}

large-scale multi-developer projects. This is a relatively recent (2004) change from an older but broadly similar system, CVS.

Read access to the entire repository is public, but write access is limited to commit- ters. Read access includes the ability to view any point in the development history of Apache, including reviewing any single or cumulative change, brief explanations of reasons for changes (e.g., bugs fixed, new capabilities, internal improvements), the date of the change, and the person responsible for making the change.

1.3.1.2 Branches: Trunk, Development, and Stable

The code repository contains a trunk and several different branches. The default version of any file is the trunk of the repository. In Apache, this version represents work in progress. It is, by definition, untested, and it generally includes experi- mental code in at least some areas.

The current stable branch is Apache httpd 2.2, which is found in/branches/2.2.x/.

Also maintained (albeit minimally) are the older 2.0 and 1.3 branches, although nei- ther is the subject of much developer effort.

New branches may also be created on an ad hoc basis for experimental code. For example, a substantial reworking of parts of the core code took place while Apache 2.2 was in beta testing, to support asynchronous I/O. This code was ini- tially too experimental to develop in the trunk, so the developers involved in this work created a new development branch. The new codebase has subsequently sta- bilized and been merged into the trunk, and should eventually be included in the next stable release (version 2.4).

1.3 The Apache Development Process 7

1.3.1.3 Review and Consensus

The Apache developers operate under different development policies for stable and development code:

• Stable code is always Review-Then-Commit (RTC). That means any code going into a branch marked as stable—even the most trivial patch—musthave been through a proper review process.

• Development code is Commit-Then-Review (CTR). That means code can be added, changed, or removed by a committer acting unilaterally, and reviewed in place by other developers (of course, SVN makes it easy to reverse a change where necessary). Nevertheless, major changes should be reviewed before com- mitting, or worked on in a separate development branch.

1.3.1.4 Backports

New code is first added to the trunk. If a developer wants this code to become part of a stable branch (typically a minor enhancement or bug fix), it is proposed for backporting. The mechanism for this is a file called STATUS, which contains a list

of current issues including votes for backport.

To qualify for backporting, any change must collect at least three positive votes from committers. A positive vote means that the voter has reviewed the change and is satisfied with it, so three such votes is a fairly good indicator that the change is sound. Even simple bug fixes are subject to this rule, which means that noncritical bugs can sometimes take a frustratingly long time to fix while awaiting attention from enough committers. Having collected three positive votes and no veto, a change may be added to a stable branch.

A committer who reviews a change and is not happy with it may note his or her reservations about it, or even veto the change. The rules require that a veto must be accompanied by an explanation and/or an alternative proposal for accomplishing the objectives of the change. A vetoed change may be either dropped or revised to deal with the objections and submitted for a new vote. A veto or a non-veto reservation will typically be resolved by discussion of the relevant issues in the developer forums.

1.3.1.5 Releases

From time to time, a new release of Apache is made available. Releases of the current stable codebase (versions 2.2.x at the time of this book’s writing) give users the

advantages of the most recent improvements and bug fixes. Such releases will be marked as the best available version and recommended to users. A release is usually prompted by developers thinking that enough minor changes have accumulated to warrant a new version, but may also be hurried if a security problem comes to the developers’ attention. A developer will volunteer to be release managerto deal with the administrative issues and create the release, while others will concentrate on applying any approved and pending updates in the STATUSfile for the stable codebase.

Current policy is that even-numbered branches are stable, while odd-numbered branches are intended for development. (This policy represents a change from earlier versions: Apache 1.3 is stable, but early 2.0 releases were not.) Thus 2.0.x (since April 2002) and 2.2.x releases are stable, while 2.1.x releases were intended for alpha testing and later beta testing for Apache 2.2. Version 2.1 was approximately 10 months in alpha testing and 3 months in beta testing before its final release as stable version 2.2. A released version should build, install, and run cleanly on any supported platform. For stable releases, meeting these criteria is a must; for development releases, it is also the intention, though it is less critical. To ensure that the release satisfies these conditions, the release manager first creates a build for the release from the appro- priate SVN branch, and then announces it to the Apache developers and testers. This allows enough time for many developers and testers to install and run the build version on a wide range of different hardware, operating systems, and applications before it is announced to the general public. If a serious problem arises in this test- ing, the build is not released.

All releases are PGP-signed by the release manager responsible. Public keys for many Apache developers, including all release managers, are available at

http://www.apache.org/dist/httpd/KEYS.