3. Development Model

3.1. Synopsis

A development model describes how development takes place, and in the case of FreeBSD, is an open and flexible process which allows literally hundreds of contributors take part in development.

There isn't an overhead to contributing to the FreeBSD project; all contributions, whether by first-time or well-known contributors are evaluated, assigned to someone, and implemented (perhaps with modifications) if found to be sound. While problem reports with patches are encouraged and appreciated if you're able to provide them, they aren't necessary for the problem report to be considered.

There are two important systems in place to aid development and contribution: The Concurrent Versions System (CVS) and the GNATS Problem Report (PR) system.

The project is staff by nearly 200 dedicated developers.

3.2. GNATS Problem Report system

The PR system handles Problem Reports, and maintains information on the problem, and allows the problem to be assigned to a developer or group, and maintains a log of state changes and email correspondence about the problem.

Here are a list of states available to problem reports:

Example 2. Problem Reports states

open

The problem report has just arrived and has not been analyzed or assigned, or it still reflects a problem that exists.

closed

The problem report does not (any longer, or never did) reflect a problem that exists.

feedback

The developers need more information about the problem to diagnose or fix the problem.

analyzed

The problem exists, and is understood, and the fix will be forthcoming.

suspended

The problem either can not be fixed at this time, or that the problem is fixed in some branches and not on the others.

3.3. Concurrent Versions System

The Concurrent Versions System allows FreeBSD to maintain a code history from early 1994 onwards [1].

CVS allows many developers to work on the source tree at the same time, and the code history aids bugfixing by showing what changes have been made recently. A side effect is that it helps users replicate source updates by revision, and not forcing them to re-download the entire source tree whenever they want to upgrade.

Here is an example of a change log generated by CVS:

Example 3. CVS log

    lile        1999/09/15 16:09:10 PDT
    
      Modified files:        (Branch: RELENG_3)
        sys/netinet          if_ether.c
      Log:
      MFC fix for truncated token-ring arp replies.
    
      Reorder arp code to make ethernet arp's the default and
      allow fddi to arp correctly.
    
      Reported by: Russell Neeper <r-neeper@tamu.edu>
      Reviewed by: Eivind Eklund <eivind@freebsd.org>
      Approved by: Jordan K. Hubbard <jkh@freebsd.org>
    
      Revision  Changes    Path
      1.52.2.4  +57 -37    src/sys/netinet/if_ether.c
        

As an explanation, this log describes a commit by the committer lile (who happens to be Larry Lile), who changed the file if_ether.c. This commit is in fact a Merge From Current or an MFC, which means that these changes were first tested in the development branch before entering the stable branch RELENG_3.

This commit fixes a problem reported by Russel Neeper, and these changes were reviewed by Eivind Eklund. In addition, since this commit occurred during a code freeze on the stable branch, the release engineer Jordan K. Hubbard approved it.

3.4. Project Staff

The FreeBSD "staff" are "committers", who have write access to the CVS tree, and thus can make direct modifications to the FreeBSD source distribution. Outside contributors are able to suggest and submit bugfixes and feedback, but these must go through the committers. There are 190 committers at present, from 141 last year this time. There are 7 South African committers.

Some committers are part of the "core team", whose task is to make sure that the project is in good shape and heading in the right directions. For example, core team members invite developers to become developers to become committers, and provide arbitration should there be differences of opinion or questional behaviour. These "powers" are more accurately described as responsibilities, and any "power" of the core team lies in the group in unison, not the individual members. There are 16 core team members. There is one South African in the Core Team "Alumni".

Outside contributors make up the bulk of developers, and provide a large portion of changes and feedback. There are over a thousand contributors listed in the "Additional Contributors" section of the FreeBSD handbook.

Notes

[1]

Previous code history had to be removed due to legal problems