Chapter 6. Processes

Table of Contents
6.1. Adding new and removing old committers
6.2. Committing code
6.3. Core election
6.4. Development of new features
6.5. Maintenance
6.6. Problem reporting
6.7. Reacting to misbehavior
6.8. Release engineering

The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases.

6.1. Adding new and removing old committers

The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges.

Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected.

If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer.

When a contributor is given committer status, they are assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon themselves to be the new committers mentor.

When a contributor is given their commit bit, a PGP-signed email is sent from either Core Secretary, Ports Manager, or to both, the assigned mentor, the new committer, and core confirming the approval of a new account. The mentor then gathers a password line, SSH 2 public key, and PGP key from the new committer and sends them to Admin. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process.

Figure 6.1. Process summary: adding a new committer
Refer to paragraph below for a screen-reader friendly version.

When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If they recommend this to core, core will vote on this recommendation. If the vote is in favour, a mentor is assigned the new committer and the new committer has to email their details to the administrators for an account to be created. After this, the new committer is all set to make their first commit. By tradition, this is by adding their name to the committers list.

Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. [FreeBSD, 2002H] There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see section 1.5.8.

Figure 6.2. Process summary: removing a committer
Refer to paragraph below for a screen-reader friendly version.

When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit bits revoked and their account removed by the administrators.

It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask.

Roles in this process:

[FreeBSD, 2000A] [FreeBSD, 2002H] [FreeBSD, 2002I]

All FreeBSD documents are available for download at

Questions that are not answered by the documentation may be sent to <>.
Send questions about this document to <>.