Index: head/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml
===================================================================
--- head/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml (revision 54305)
+++ head/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml (revision 54306)
@@ -1,209 +1,225 @@
+ &a.kmoore.email; (2016 - 2020)
+
+
+
+ &a.jhb.email; (2002 - 2006, 2010 - 2014, 2016 - 2020)
+
+
+
+ &a.jeff.email; (2018 - 2020)
+
+
+
+ &a.brooks.email; (2006 - 2012, 2018 - 2020)
+
+
+
+ &a.bcr.email; (2016 - 2020)
+
+
+
+ &a.allanjude.email; (2016 - 2020)
+
+
+ &a.bapt.email; (2016 - 2018)&a.emaste.email; (2016 - 2018)&a.gnn.email; (2006 - 2010, 2016 - 2018)&a.benno.email; (2016 - 2018)&a.tabthorpe.email; (2012 - 2014)
- &a.jhb.email; (2002 - 2006, 2010 - 2014)
-
-
- &a.kib.email; (2010 - 2014)&a.miwi.email; (2012 - 2014)&a.attilio.email; (2012)&a.wilko.email; (2006 - 2012)
-
-
-
- &a.brooks.email; (2006 - 2012)&a.imp.email; (2000 - 2008, 2010 - 2012)&a.pav.email; (2010 - 2012)&a.cperciva.email; (2010 - 2012)&a.rwatson.email; (2000 - 2012)&a.keramida.email; (2006 - 2010)&a.kris.email; (2008 - 2010)&a.murray.email; (2002 - 2010)&a.peter.email; (1995 - 2006, 2008 - 2010)&a.wes.email; (2002 - 2008)&a.markm.email; (2002 - 2006)&a.kuriyama.email; (2002 - 2006)&a.scottl.email; (2004 - 2005)&a.grog.email; (2000 - 2004)&a.dg.email; (1992 - 2002)&a.dfr.email; (1999 - 2002)&a.msmith.email; (2000 - 2002)&a.jkh.email; (1992 - 2002)&a.asami.email; (1993 - 2001)&a.ache.email; (1993 - 2000)&a.jmb.email; (1993 - 2000)&a.bde.email; (1992 - 2000)&a.gibbs.email; (1993 - 2000)&a.rich.email; (1994 - 2000)&a.phk.email; (1992 - 2000)&a.gpalmer.email; (1993 - 2000)&a.sos.email; (1993 - 2000)&a.wollman.email; (1993 - 2000)&a.joerg.email; (1995 - 2000)&a.jdp.email; (1997 - 2000)&a.guido.email; (1995 - 1999)&a.dyson.email; (1993 - 1998)&a.nate.email; (1992 - 1996)&a.rgrimes.email; (1992 - 1995)&a.ats.email; (1992 - 1995)&a.csgr.email; (1993 - 1995)&a.paul.email; (1992 - 1995)&a.smace.email; (1993 - 1994)&a.alm.email; (1993 - 1994)&a.chmr.email; (1993 - 1994)&a.jtc.email; (1992 - 1993)
Index: head/en_US.ISO8859-1/books/dev-model/book.xml
===================================================================
--- head/en_US.ISO8859-1/books/dev-model/book.xml (revision 54305)
+++ head/en_US.ISO8859-1/books/dev-model/book.xml (revision 54306)
@@ -1,2965 +1,2965 @@
%chapters;
]>
A project model for the FreeBSD ProjectNiklasSaers2002-2005Niklas Saers1.6November, 2019Style revisions, accessibility enhancements,
and statistics updates throughout the book.1.5October, 2014Remove mention of GNATS which is no longer
used by the project.1.4September, 2013Remove mention of CVS and CVSup which are no
longer used by the project.1.3October, 2012Remove hats held by specific people, these
are documented elsewhere.1.2April, 2005Update one year of changes, replace statistics with those of 20041.1July, 2004First update within the FreeBSD tree1.0December 4th, 2003Ready for commit to FreeBSD Documentation0.7April 7th, 2003Release for review by the Documentation team0.6March 1st, 2003Incorporated corrections noted by
interviewees and reviewers0.5February 1st, 2003Initial review by interviewees$FreeBSD$Foreword
Up until now, the FreeBSD project has released a number of
described techniques to do different parts of work. However,
a project model summarising how the project is structured is needed
because of the increasing amount of project members.
This goes hand-in-hand with Brooks' law that adding
another person to a late project will make it later
since it will increase the communication needs .
A project model
is a tool to reduce the communication needs.
This paper
will provide such a project model and is donated to the
FreeBSD Documentation project where it can evolve together with
the project so that it can at any point in time reflect the way
the project works. It is based on .
I would like to thank the following people for taking the time
to explain things that were unclear to me and for proofreading
the document.Andrey A. Chernov ache@freebsd.orgBruce A. Mah bmah@freebsd.orgDag-Erling Smørgrav des@freebsd.orgGiorgos Keramidaskeramida@freebsd.orgIngvil Hovig ingvil.hovig@skatteetaten.noJesper Holckjeh.inf@cbs.dkJohn Baldwin jhb@freebsd.orgJohn Polstra jdp@freebsd.orgKirk McKusick mckusick@freebsd.orgMark Linimon linimon@freebsd.orgMarleen DevosNiels Jørgenssennielsj@ruc.dkNik Clayton nik@freebsd.orgPoul-Henning Kamp phk@freebsd.orgSimon L. Nielsen simon@freebsd.orgOverview
A project model is a means to reduce the communications overhead in
a project. As shown by , increasing the
number of project participants increases the communication in the
project exponentionally. FreeBSD has during the past few years
increased both its mass of active users and committers, and the
communication in the project has risen accordingly. This project
model will serve to reduce this overhead by providing an up-to-date
description of the project.
During the Core elections in 2002, Mark Murray stated
I am opposed to a long rule-book, as that satisfies
lawyer-tendencies, and is counter to the technocentricity that
the project so badly needs..
This project model is not meant to be a tool to
justify creating impositions for developers, but as a tool to
facilitate coordination.
It is meant as a
description of the project, with an overview of how the different
processes are executed.
It is an introduction to how the FreeBSD
project works.
The FreeBSD project model will be described as of
July 1st, 2004. It is based on the Niels Jørgensen's paper
,
FreeBSD's official documents,
discussions on FreeBSD mailing lists and interviews with
developers.
After providing definitions of terms used, this document will outline
the organisational structure (including role descriptions and
communication lines),
discuss the methodology model and after presenting the
tools used for process control, it will present the defined
processes. Finally it will outline major sub-projects of the
FreeBSD project.
, Section 1.2 and 1.3
give the vision and the architectural guidelines for the
project. The vision is To produce the best UNIX-like
operating system package possible, with due respect to the
original software tools ideology as well as usability,
performance and stability. The architectural
guidelines help determine whether a problem that someone wants
to be solved is within the scope of the project
DefinitionsActivity
An activity is an element of work performed
during the course of a project .
It has an output and
leads towards an outcome.
Such an output can either be an input to another
activity or a part of the process' delivery.
Process
A process is a series of activities
that lead towards a particular outcome. A process can
consist of one or more sub-processes. An example of a process is software
design.
Hat
A hat is synonymous with role. A hat has
certain responsibilities in a process and for the process
outcome. The hat executes activities. It is well defined what
issues the hat should be contacted about by the project
members and people outside the project.
Outcome
An outcome is the final output of the process.
This is synonymous with deliverable, that is defined as
any measurable, tangible, verifiable outcome, result or
item that must be produced to complete a project or part of a
project. Often used more narrowly in reference to an external
deliverable, which is a deliverable that is subject to approval
by the project sponsor or customer by .
Examples of
outcomes are a piece of software, a decision made or a
report written.
FreeBSD
When saying FreeBSD we will mean the BSD
derivative UNIX-like operating system
FreeBSD, whereas when saying the FreeBSD
Project we will mean the project organisation.
Organisational structure
While no-one takes ownership of FreeBSD, the FreeBSD
organisation is divided into core, committers and contributors
and is part of the FreeBSD community that lives around it.
The FreeBSD Project's structure (in order of descending authority)
GroupNumber of peopleCore members9Committers269Contributors~3000
Number of committers has been determined by going through
CVS logs from January 1st, 2004 to December 31st, 2004 and
contributors by going through the list of contributions and
problem reports.
The main resource in the FreeBSD community is its developers: the
committers and contributors. It is with their contributions that the
project can move forward. Regular developers are referred to as contributors.
As of January 1st, 2003, there are an estimated 5500
contributors on the project.
Committers are developers with the privilege of being able to
commit changes. These are usually the
most active developers who are willing to
spend their time not only integrating their own code but
integrating code submitted by the developers who
do not have this privilege. They are also the developers who elect
the core team, and they have access to closed discussions.
The project can be grouped into four distinct separate parts,
and most developers will focus their involvement in one
part of FreeBSD.
The four parts
are kernel development, userland development, ports and
documentation. When referring to the base system, both
kernel and userland is meant.
This split changes our table to look like this:
The FreeBSD Project's structure with committers in categories
GroupCategoryNumber of peopleCore members9CommittersKernel56Userland50Docs9Ports120Total269Contributors~3000
Number of committers per area has been determined by going through
CVS logs from January 1st, 2004 to December 31st, 2004.
Note that many committers work in multiple
areas, making the total number higher than the real number
of committers. The total number of committers at that
time was 269.
Committers fall into three
groups: committers who are only concerned with one area of
the project (for instance file systems), committers who
are involved only with one sub-project,
and committers who commit to different parts
of the code, including sub-projects.
Because some committers work on different parts, the total
number in the committers section of the table is higher than
in the above table.
The kernel is the main building block of FreeBSD. While
the userland applications are protected against faults in
other userland applications, the entire system is
vulnerable to errors in the kernel. This, combined with the
vast amount of dependencies in the kernel and that it is not easy to
see all the consequences of a kernel change, demands
developers with a relative full understanding of the
kernel. Multiple development efforts in the kernel also
require a closer coordination than userland applications do.
The core utilities, known as userland, provide the interface that identifies
FreeBSD, both user interface, shared libraries and external interfaces to
connecting clients. Currently, 162 people are involved in userland
development and maintenance, many being maintainers for
their own part of the code.
Maintainership will
be discussed in the section.
Documentation is handled by
and includes all documents surrounding the
FreeBSD project, including the web pages. There were during 2004 101
people making commits to the FreeBSD Documentation Project.
Ports is the collection of meta-data that is needed to make
software packages build correctly on FreeBSD. An example of a port
is the port for the web-browser Mozilla. It contains
information about where to fetch the source, what patches to
apply and how, and how the package should be installed on the
system. This allows automated tools to fetch, build and
install the package. As of this writing, there are more than
12600 ports available.
Statistics are generated by counting the number of
entries in the file fetched by portsdb by April 1st, 2005.
portsdb is a part of the port sysutils/portupgrade.
, ranging
from web servers to games, programming languages and most of the
application types that are in use on modern computers.
Ports will be discussed further in the section
.
Methodology modelDevelopment model
There is no defined model for how people write code in
FreeBSD. However, Niels Jørgenssen has suggested a model of
how written code is integrated into the project.
Jørgenssen's model for change integration
StageNext if successfulNext if unsuccessfulcodereviewreviewpre-commit testcodepre-commit testdevelopment releasecodedevelopment releaseparallel debuggingcodeparallel debuggingproduction releasecodeproduction releasecode
The development release is the FreeBSD-CURRENT
("-CURRENT") branch and the production release
is the FreeBSD-STABLE branch ("-STABLE")
.
This is a model for one change, and shows that after
coding, developers seek community review and
try integrating it with their own systems. After integrating the change
into the development release, called FreeBSD-CURRENT, it is tested
by many users and developers in the FreeBSD community. After it
has gone through enough testing, it is merged into the production
release, called FreeBSD-STABLE. Unless each stage is finished
successfully, the developer needs to go back and make
modifications in the code and restart the process. To integrate a
change with either -CURRENT or -STABLE is called making a commit.
Jørgensen found that most FreeBSD developers work
individually, meaning that this model is used in parallel by
many developers on the different ongoing development efforts. A
developer can also be working on multiple changes, so that while
they are waiting for review or people to test one or more of their
changes, they may be writing another change.
As each commit represents an increment, this is a massively
incremental model. The commits are in fact so frequent that
during one year
The period from January 1st, 2004 to December 31st, 2004 was
examined to find this number.
, 85427 commits were made, making a daily average of 233
commits.
Within the code bracket in Jørgensen's
model, each programmer has their own working style and follows their
own development models. The bracket could very well have been
called development as it includes requirements
gathering and analysis, system and detailed design,
implementation and verification. However, the only
output from these stages is the source code or system documentation.
From a stepwise model's perspective (such as the waterfall
model), the other brackets can be seen as further verification
and system integration. This system integration is also important
to see if a change is accepted by the community. Up until the
code is committed, the developer is free to choose how much to
communicate about it to the rest of the project. In order for
-CURRENT to work as a buffer (so that bright ideas that had some
undiscovered drawbacks can be backed out) the minimum time a
commit should be in -CURRENT before merging it to -STABLE is 3
days. Such a merge is referred to as an MFC (Merge From Current).
It is important to notice the word change. Most
commits do not contain radical new features, but are maintenance
updates.
The only exceptions from this model are security fixes and
changes to features that are deprecated in the -CURRENT branch.
In these cases, changes can be committed directly to the -STABLE branch.
In addition to many people working on the project, there are
many related projects to the FreeBSD Project. These are either
projects developing brand new features,
sub-projects or projects whose outcome is incorporated into
FreeBSD
For instance, the development of the Bluetooth stack started
as a sub-project until it was deemed stable enough to be
merged into the -CURRENT branch. Now it is a part of the core
FreeBSD system.
.
These projects fit into the FreeBSD Project just like regular
development efforts: they produce code that is integrated with
the FreeBSD Project. However, some of them (like Ports and
Documentation) have the privilege of being applicable to both
branches or commit directly to both -CURRENT and -STABLE.
There is no standards to how design should be done, nor is
design collected in a centralised repository.
The main design is that of 4.4BSD.
According to Kirk McKusick, after 20 years of developing
UNIX operating systems, the interfaces are for the most part
figured out. There is therefore no need for much
design. However, new applications of the system and new hardware leads to
some implementations being more beneficial than those that
used to be preferred. One example is the introduction of web
browsing that made the normal TCP/IP connection a short
burst of data rather than a steady stream over a longer
period of time.
As design is a part of the Code bracket in
Jørgenssen's model, it is up to every developer or
sub-project how this should be done.
Even if the design should be stored in a central repository,
the output from the design stages would be of limited use as
the differences of methodologies would make them poorly if at
all interoperable. For the overall design of the project, the
project relies on the sub-projects to negotiate fit interfaces
between each other rather than to dictate interfacing.
Release branches
The releases of FreeBSD are best illustrated by a tree with many
branches where each major branch represents a major
version. Minor versions are represented by branches of the
major branches.
In the following release tree, arrows that follow one-another
in a particular direction
represent a branch. Boxes with full lines and diamonds represent official
releases. Boxes with dotted lines represent the development
branch at that time. Security branches are represented by ovals.
Diamonds differ from boxes in that they
represent a fork, meaning a place where a branch splits into two
branches where one of the branches becomes a sub-branch.
For example,
at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and
5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security
branch called RELENG_4_5.
Major releaseForked fromFollowing minor releases…3.0 Current (development branch)Releng 3 branches: 3.0 Release to
3.5 Release, leading to 3.5.1 Release
and the subsequent 3 Stable branch
4.0 Current (development branch)3.1 ReleaseReleng 4 branches: 4.1 Release to
4.6 Release (and 4.6.2 Release), then
4.7 Release to 4.11 Release (all
starting at 4.3 Release also leading to
a Releng_4_n branch), and the
subsequent 4 Release branch
5.0 Current (development branch)4.0 ReleaseReleng 5 branches: 5.0 Release to
5.4 Release (all except 5.0 and 5.3
also leading to a Releng_5_n branch),
and the subsequent 5 Release branch
6.0 Current (development branch)5.3 Release…
The latest -CURRENT version
is always referred to as -CURRENT, while the latest -STABLE
release is always referred to as -STABLE. In this figure,
-STABLE refers to 4-STABLE while -CURRENT refers to
5.0-CURRENT following 5.0-RELEASE.
A major release is always made from the -CURRENT branch.
However, the -CURRENT branch does not need to fork at that point in time,
but can focus on stabilising. An example of this is that following
3.0-RELEASE, 3.1-RELEASE was also a continuation of the
-CURRENT-branch, and -CURRENT did not become a true development
branch until this version was released and the 3-STABLE branch
was forked. When
-CURRENT returns to becoming a development branch, it can only be
followed by a major release. 5-STABLE is predicted to be forked
off 5.0-CURRENT at around 5.3-RELEASE. It is not until
5-STABLE is forked that the development branch will be branded 6.0-CURRENT.
A minor release is made from the -CURRENT branch
following a major release, or from the -STABLE branch.
Following and including, 4.3-RELEASE
The first release this actually happened for was 4.5-RELEASE,
but security branches were at the same time created for
4.3-RELEASE and 4.4-RELEASE.
, when a minor release has been made, it becomes a security
branch. This is meant for organisations that do not want
to follow the -STABLE branch and the potential new/changed features it
offers, but instead require an absolutely stable environment, only
updating to implement security updates.
There is a terminology
overlap with respect to the word "stable", which leads to some
confusion. The -STABLE branch is still a
development branch, whose goal is to be
useful for most people.
If it is never acceptable for a system to get changes that
are not announced at the time it is deployed,
that system should run a security branch.
Each update to a security branch
is called a patchlevel. For every security
enhancement that is done, the patchlevel number is increased,
making it easy for people tracking the branch to see what
security enhancements they have implemented. In cases where there
have been especially serious security flaws, an entire new release
can be made from a security branch. An example of this is
4.6.2-RELEASE.
Model summary
To summarise, the development model of FreeBSD can be seen as
the following tree:
The tree of the FreeBSD development with ongoing development
efforts and continuous integration.
The tree symbolises the release versions with major versions
spawning new main branches and minor versions being versions of
the main branch. The top branch is the -CURRENT branch where all
new development is integrated, and the -STABLE branch is the
branch directly below it. Below the -STABLE branch are old,
unsupported versions.
Clouds of development efforts hang over the project
where developers use the development models they see fit. The
product of their work is then integrated into -CURRENT where it
undergoes parallel debugging and is finally merged from -CURRENT into
-STABLE. Security fixes are merged from -STABLE to the security branches.
Hats
Many committers have a special area of responsibility. These
roles are called hats.
These hats can
be either project roles, such as public relations officer, or
maintainer for a certain area of the
code. Because this is a project where people give voluntarily of
their spare time, people with assigned hats are not always
available. They must therefore appoint a deputy that can perform
the hat's role in their absence. The other option is to have
the role held by a group.
Many of these hats are not formalised. Formalised hats have a
charter stating the exact purpose of the hat along with its
privileges and responsibilities. The writing of such charters is
a new part of the project, and has thus yet to be completed for
all hats. These hat descriptions are not such a formalisation,
rather a summary of the role with links to the charter where
available and contact addresses.
General HatsContributor
A Contributor contributes to the FreeBSD project either as a
developer, as an author, by sending problem reports, or in
other ways contributing to the progress of the project. A
contributor has no special privileges in the FreeBSD project.
Committer
A person who has the required privileges to add their code or documentation to the
repository.
A committer has made a commit within the past 12 months.
An active committer is a committer
who has made an average of one commit per month during that time.
It is worth noting that there are no technical barriers to prevent
someone, once having gained commit privileges to the main- or a sub-project, to make commits in
parts of that project's source the committer did not specifically get
permission to modify. However, when wanting to make
modifications to parts a committer has not been involved in
before, they should read the logs to see what has happened
in this area before, and also read the MAINTAINERS file to see if
the maintainer of this part has any special requests on how
changes in the code should be made.
Core Team
The core team is elected by the committers from the pool of committers
and serves as the board of directors of the FreeBSD project. It
promotes active contributors to committers, assigns people to
well-defined hats, and is the final arbiter of decisions involving
which way the project should be heading.
As of July 1st, 2004, core consisted of 9 members.
Elections are held every two years.
Maintainership
Maintainership means that that person is responsible for
what is allowed to go into that area of the code and has the
final say should disagreements over the code occur. This
involves proactive work aimed at stimulating
contributions and reactive work in reviewing commits.
With the FreeBSD
source comes the MAINTAINERS file that contains a one-line
summary of how each maintainer would like contributions to be
made. Having this notice and contact information
enables developers to focus on the development effort rather
than being stuck in a slow correspondence should the maintainer
be unavailable for some time.
If the maintainer is unavailable for an unreasonably long period
of time, and other people do a significant amount of work,
maintainership may be switched without the maintainer's approval.
This is based on the stance that maintainership should be
demonstrated, not declared.
Maintainership of a particular piece of code is a hat that
is not held as a group.
Official Hats
The official hats in the FreeBSD Project are hats that are more
or less formalised and mainly administrative roles. They have
the authority and responsibility for their area. The following
list shows the responsibility lines and gives
a description of each hat, including who it is held by.
Documentation project manager
architect is responsible for
defining and following up documentation goals for the
committers in the Documentation project, which they
supervise.
Hat held by:
The DocEng team doceng@FreeBSD.org.
The
DocEng Charter.
Postmaster
The Postmaster is responsible for mail being correctly
delivered to the committers' email address. They are also
responsible for ensuring that the mailing lists work and
should take measures against possible disruptions of mail
such as having troll-, spam- and virus-filters.
Hat currently held by:
the Postmaster Team postmaster@FreeBSD.org.
Release Coordination
The responsibilities of the Release Engineering Team are
Setting, publishing and following a release schedule for
official releases
Documenting and formalising release engineering procedures
Creation and maintenance of code branches
Coordinating with the Ports and Documentation teams
to have an updated set of packages and documentation
released with the new releases
Coordinating with the Security team so that pending
releases are not affected by recently disclosed vulnerabilities.
Further information about the development process is
available in the section.
Hat held by:
the Release Engineering team re@FreeBSD.org.
The
Release Engineering Charter.
Public Relations & Corporate Liaison
The Public Relations & Corporate Liaison's
responsibilities are:
Making press statements when happenings that are
important to the FreeBSD Project happen.
Being the official contact person for corporations that
are working close with the FreeBSD Project.
Take steps to promote FreeBSD within both the Open Source
community and the corporate world.
Handle the freebsd-advocacy mailing list.
This hat is currently not occupied.
Security Officer
The Security Officer's main responsibility is to
coordinate information exchange with others in the
security community and in the FreeBSD project.
The Security Officer is also responsible for taking action
when security problems are reported and promoting proactive
development behavior when it comes to security.
Because of the fear that information about
vulnerabilities may leak out to people with malicious
intent before a patch is available, only the Security
Officer, consisting of an officer, a deputy and two
members, receive sensitive
information about security issues. However, to create or
implement a patch, the Security Officer has the Security
Officer Team security-team@FreeBSD.org to
help do the work.
Source Repository Manager
The Source Repository Manager is the only one who is allowed
to directly modify the repository without using the
tool.
It is their
responsibility to ensure that technical problems that arise in the
repository are resolved quickly. The source repository
manager has the authority to back out commits if this is
necessary to resolve a SVN technical problem.
Hat held by:
the Source Repository Manager clusteradm@FreeBSD.org.
Election Manager
The Election Manager is responsible for the
process. The manager
is responsible for running and maintaining the election
system, and is the final authority should minor unforeseen
events happen in the election process. Major unforeseen
events have to be discussed with the
Hat held only during elections.
Web site Management
The Web site Management hat is responsible for coordinating
the rollout of updated web pages on mirrors around the world,
for the overall structure of the primary web site and the
system it is running upon. The management needs to
coordinate the content with
and acts as
maintainer for the www tree.
Hat held by:
the FreeBSD Webmasters www@FreeBSD.org.
Ports Manager
The Ports Manager acts as a liaison between
and the core project, and
all requests from the project should go to the ports manager.
Hat held by:
the Ports Management Team portmgr@FreeBSD.org.
The
Portmgr charter.
Standards
The Standards hat is responsible for ensuring that FreeBSD
complies with the standards it is committed to , keeping up to date
on the development of these standards and notifying
FreeBSD developers of important changes that allows them to take a
proactive role and decrease the time between a standards
update and FreeBSD's compliancy.
Hat currently held by:
Garrett Wollman wollman@FreeBSD.org.
Core Secretary
The Core Secretary's main responsibility is to write drafts to
and publish the final Core Reports. The secretary also keeps
the core agenda, thus ensuring that no balls are dropped
unresolved.
- Hat currently held by: &a.jrm.email;.
+ Hat currently held by: &a.bofh.email;.
Bugmeister
The Bugmeister is responsible for ensuring that the
maintenance database is in working order, that the entries
are correctly categorised and that there are no invalid entries. They supervise bugbusters.
Hat currently held by:
the Bugmeister Team bugmeister@FreeBSD.org.
Donations Liaison Officer
The task of
the donations liaison officer is to match
the developers with needs with people or
organisations willing to make a
donation.
Hat held by:
the Donations Liaison Office donations@FreeBSD.org.
The
Donations Liaison Charter.
Admin
(Also called FreeBSD Cluster Admin)
The admin team consists of the
people responsible for administrating the
computers that the project relies on for
its distributed work and communication to
be synchronised. It consists mainly of those
people who have physical access to the
servers.
Hat held by:
the Admin team admin@FreeBSD.org.
Process dependent hatsReport originator
The person originally responsible for
filing a Problem Report.
Bugbuster
A person who will either find the right
person to solve the problem, or close the PR if
it is a duplicate or otherwise
not an interesting one.
Mentor
A mentor is a committer who takes it upon them to
introduce a new committer to the project, both in terms of
ensuring the new committer's setup is valid,
that the new committer knows the available tools required in
their work, and that the
new committer knows what is expected of them in terms of
behavior.
Vendor
The person(s) or organisation whom
external code comes from and whom patches are sent to.
Reviewers
People on the mailing list where the request
for review is posted.
Processes
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.
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 -signed email is sent
from either ,
, or nik@freebsd.org to both
admins@freebsd.org, the assigned mentor, the new committer, and
core confirming the approval of a new account. The mentor then
gathers a password line, public key, and PGP key from the
new committer and sends them to . When the new account is created, the
mentor activates the commit bit and guides the new committer
through the rest of the initial process.
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.
There are, however, no
automatic procedures for doing this.
For reactions concerning commit privileges not triggered by
time, see section 1.5.8.
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:
Committing code
The committing of new or modified code is one of the most
frequent processes in the FreeBSD project and will usually
happen many times a day. Committing of code can only be done
by a committer. Committers commit either code
written by themselves, code submitted to them, or code
submitted through a problem
report.
When code is written by the developer that is non-trivial, they
should seek a code review from the community. This
is done by sending mail to the relevant list asking for
review. Before submitting the code for review, they should
ensure it compiles correctly with the entire tree and that all
relevant tests run. This is called pre-commit
test. When contributed code is received, it should be
reviewed by the committer and tested the same way.
When a change is committed to a part of the source that
has been contributed from an outside
,
the maintainer should
ensure that the patch is contributed back to the
vendor. This is in line with the open source
philosophy and
makes it easier to stay in sync with outside projects
as the patches do not have to be reapplied every time a
new release is made.
After the code has been available for review and no further
changes are necessary, the code is committed into the
development branch, -CURRENT.
If the change applies for
the -STABLE branch or the other branches as well, a
Merge From Current ("MFC") countdown is
set by the committer. After the number of days the
committer chose when setting the MFC have passed, an email
will automatically be
sent to the committer reminding them to commit it to the -STABLE
branch (and possibly security branches as well). Only security
critical changes should be merged to security branches.
Delaying the commit to -STABLE and other branches allows for
parallel debugging where the committed code is
tested on a wide range of configurations. This makes changes
to -STABLE to contain fewer faults and thus giving the branch
its name.
When a committer has written a piece of code and
wants to commit it, they first need to determine if it is
trivial enough to go in without prior review or if it should
first be reviewed by the developer community. If the code is
trivial or has been reviewed and the committer is not the
maintainer, they should consult the maintainer before
proceeding.
If the code is contributed by an outside vendor, the
maintainer should create a patch that is sent back to the
vendor. The code is then committed and then deployed by
the users. Should they find problems with the code, this
will be reported and the committer can go back to writing
a patch. If a vendor is affected, they can choose to
implement or ignore the patch.
The difference when a contributor makes a code contribution is
that they submit the code through the Bugzilla
interface. This report is picked up by the maintainer who
reviews the code and commits it.
Hats included in this process are:
Core election
Core elections are held at least every two years.
The first Core election was held September 2000
Nine core members are elected. New elections are held if
the number of core members drops below seven. New elections can
also be held should at least 1/3 of the active committers demand this.
When an election is to take place, core announces this at
least 6 weeks in advance, and appoints an election manager to
run the elections.
Only committers can be elected into core. The candidates need
to submit their candidacy at least one week before the
election starts, but can refine their statements until the
voting starts. They are
presented in the candidates
list. When writing their election statements, the candidates
must answer a few standard questions submitted by the election manager.
During elections, the rule that a committer must have
committed during the 12 past months is followed strictly.
Only these committers are eligible to vote.
When voting, the committer may vote once in support of up to
nine nominees. The voting is done over a period of four weeks
with reminders being posted on developers
mailing list that is available to all committers.
The election results are released one week after the election
ends, and the new core team takes office one week after the
results have been posted.
Should there be a voting tie, this will be resolved by
the new, unambiguously elected core members.
Votes and candidate statements are archived, but the archives
are not publicly available.
Core announces the election and selects an election
manager who prepares the elections, and when ready,
candidates can announce their candidacies through
submitting their statements. The committers then vote.
After the vote is over, the election results are
announced and the new core team takes office.
Hats in core elections are:
Development of new features
Within the project there are sub-projects that are working on
new features. These projects are generally done by one person
.
Every project is free to
organise development as it sees fit. However, when the project
is merged to the -CURRENT branch it must follow the project
guidelines. When the code has been well tested in the
-CURRENT branch and deemed stable enough and relevant
to the -STABLE branch, it is merged to the -STABLE branch.
The requirements of the project are given by developer
wishes, requests from the community in terms of direct
requests by mail, Problem Reports, commercial funding for the development
of features, or contributions by the scientific community.
The wishes that come within the responsibility of a developer
are given to that developer who prioritises their time between
the request and their wishes. A common way to do this is maintain
a TODO-list maintained by the project. Items that do not come within
someone's responsibility are collected on TODO-lists unless someone
volunteers to take the responsibility. All
requests, their distribution and follow-up are
handled by the tool.
Requirements analysis happens in two ways. The requests that
come in are discussed on mailing lists, both within the main
project and in the sub-project that the request belongs to or is
spawned by the request. Furthermore, individual developers on
the sub-project will evaluate the feasibility of the requests
and determine the prioritisation between them. Other than archives
of the discussions that have taken place, no outcome is created
by this phase that is merged into the main project.
As the requests are prioritised by the individual developers on
the basis of doing what they find interesting, necessary, or are
funded to do, there is no overall strategy or prioritisation of
what requests to regard as requirements and following up their
correct implementation. However, most developers have some
shared vision of what issues are more important, and they can
ask for guidelines from the release engineering team.
The verification phase of the project is two-fold. Before
committing code to the current-branch, developers request their
code to be reviewed by their peers. This review is for the most
part done by functional testing, but also code review is
important. When the code is committed to the branch, a broader
functional testing will happen, that may trigger further code
review and debugging should the code not behave as
expected. This second verification form may be regarded as
structural verification.
Although the sub-projects themselves may write formal
tests such as unit tests, these are usually not collected by the main
project and are usually removed before the code is committed to
the current branch.
More and more tests are however performed when
building the system (make
world). These tests are however a very new
addition and no systematic framework for these
tests have yet been created.
Maintenance
It is an advantage to the project to for each area of the source
have at least one person that knows this area well.
Some parts of the code have designated
maintainers. Others have de-facto maintainers, and some
parts of the system do not have
maintainers.
The maintainer is usually a person from the sub-project that
wrote and integrated the code, or someone who has ported it from
the platform it was written for.
sendmail and named are examples of code that has been merged
from other platforms.
The maintainer's job is to make sure the code is in sync with the
project the code comes from if it is contributed code, and apply patches
submitted by the community or write fixes to issues that are
discovered.
The main bulk of work that is put into the FreeBSD project is
maintenance.
has made a figure
showing the life cycle of changes.
Jørgenssen's model for change integration
StageNext if successfulNext if unsuccessfulcodereviewreviewpre-commit testcodepre-commit testdevelopment releasecodedevelopment releaseparallel debuggingcodeparallel debuggingproduction releasecodeproduction releasecode
Here development release refers to the -CURRENT
branch while production release refers to the
-STABLE branch. The pre-commit test is the
functional testing by peer developers when asked to do so or
trying out the code to determine the status of the sub-project.
Parallel debugging is the functional testing
that can trigger more review, and debugging when the code is
included in the -CURRENT branch.
As of this writing, there were 269 committers in the
project. When they commit a change to a branch, that constitutes
a new release. It is very common for users in the community to
track a particular branch. The immediate existence of a new
release makes the changes widely available right away and allows
for rapid feedback from the community. This also gives the
community the response time they expect on issues that are of
importance to them. This makes the community more engaged, and
thus allows for more and better feedback that again spurs more
maintenance and ultimately should create a better product.
Before making changes to code in parts of the tree
that has a history unknown to the committer, the
committer is required to read the commit logs to see why
certain features are implemented the way they are in
order not to make mistakes that have previously either been
thought through or resolved.
Problem reporting
Before &os; 10, &os; included a problem reporting tool called
send-pr. Problems include bug reports,
feature requests, feature enhancements and notices of new versions
of external software that are included in the project.
Although send-pr is available, users and developers are encouraged
to submit issues using our
problem report form.
Problem reports are sent to an email address where it
is inserted into the Problem Reports maintenance database. A
classifies the problem and sends it to the
correct group or maintainer within the project. After someone
has taken responsibility for the report, the report is being
analysed. This analysis includes verifying the problem and
thinking out a solution for the problem. Often feedback is
required from the report originator or even from the FreeBSD
community. Once a patch for the problem is made, the
originator may be asked to try it out. Finally, the working patch
is integrated into the project, and documented if
applicable. It there goes through the regular maintenance
cycle as described in section .
These are the states a problem report can be in:
open, analyzed, feedback, patched, suspended and closed. The
suspended state is for when further progress is not possible
due to the lack of information or for when the task would require
so much work that nobody is working on it at the moment.
A problem is reported by the report originator. It is
then classified by a bugbuster and handed to the correct
maintainer. They verify the problem and discuss the
problem with the originator until they have enough
information to create a working patch. This patch is then
committed and the problem report is closed.
The roles included in this process are:
.
Reacting to misbehavior has a
number of rules that committers should follow. However, it
happens that these rules are broken. The following rules exist
in order to be able to react to misbehavior. They specify what
actions will result in how long a suspension of the committer's
commit privileges.
Committing during code freezes without the approval of the
Release Engineering team - 2 days
Committing to a security branch without approval - 2 days
Commit wars - 5 days to all participating parties
Impolite or inappropriate behavior - 5 days
For the suspensions to be efficient, any single core member can
implement a suspension before discussing it on the core
mailing list. Repeat offenders can, with a 2/3 vote by core,
receive harsher penalties, including permanent removal of
commit privileges. (However, the latter is always viewed as a last
resort, due to its inherent tendency to create controversy.) All
suspensions are posted to the
developers
mailing list, a list available to committers only.
It is important that you cannot be suspended for making
technical errors. All penalties come from breaking social etiquette.
Hats involved in this process:
Release engineering
The FreeBSD project has a Release Engineering team with a
principal release engineer that is responsible for creating releases
of FreeBSD that can be brought out to the user community via the
net or sold in retail outlets. Since FreeBSD is available on multiple
platforms and releases for the different architectures are made
available at the same time, the team has one person in charge of
each architecture. Also, there are roles in the team responsible
for coordinating quality assurance efforts, building a package
set and for having an updated set of documents.
When referring to the release engineer,
a representative for the release engineering team is
meant.
When a release is coming, the FreeBSD project changes shape
somewhat. A release schedule is made containing feature- and
code-freezes, release of interim releases and the final
release. A feature-freeze means no new features are allowed to
be committed to the branch without the release engineers'
explicit consent. Code-freeze means no changes to the code (like
bugs-fixes) are allowed to be committed without the release
engineers' explicit consent. This feature- and code-freeze is
known as stabilising. During the release process, the release
engineer has the full authority to revert to older versions of
code and thus "back out" changes should they find that the changes
are not suitable to be included in the release.
There are three different kinds of releases:
.0 releases are the first release of a major
version. These are branched of the -CURRENT branch
and have a significantly longer release engineering
cycle due to the unstable nature of the -CURRENT branch
.X releases are releases of the -STABLE
branch. They are scheduled to come out every 4 months.
.X.Y releases are security releases that follow
the .X branch. These come out only when sufficient
security fixes have been merged since the last
release on that branch. New features are rarely
included, and the security team is far more
involved in these than in regular releases.
For releases of the -STABLE-branch, the release process starts 45
days before the anticipated
release date. During the first phase, the first 15 days, the
developers merge what changes they have had in -CURRENT
that they want to have in the release to the release
branch. When this period is over, the code enters a 15
day code freeze in which only bug fixes, documentation updates,
security-related fixes and minor device driver changes are
allowed. These changes must be approved by the release engineer
in advance. At the beginning of the last 15 day period a release
candidate is created for widespread testing. Updates are less
likely to be allowed during this period, except for important
bug fixes and security updates. In this final period, all
releases are considered release candidates. At the end of the
release process, a release is created with the new version
number, including binary distributions on web sites and the
creation of CD-ROM images. However, the release is not
considered "really released" until a -signed message stating
exactly that, is sent to the mailing list freebsd-announce; anything
labelled as a "release" before that may well be in-process and
subject to change before the PGP-signed message is sent.
Many commercial vendors use these images to create
CD-ROMs that are sold in retail outlets.
.
The releases of the -CURRENT-branch (that is, all releases that
end with .0) are very similar, but with twice as
long timeframe. It starts 8 weeks prior to the release with
announcement of the release time line. Two weeks into the
release process, the feature freeze is initiated and performance
tweaks should be kept to a minimum. Four weeks prior to the
release, an official beta version is made available. Two weeks
prior to release, the code is officially branched into a new
version. This version is given release candidate status, and as
with the release engineering of -STABLE, the code freeze of the
release candidate is
hardened. However, development on the main development branch
can continue. Other than these differences, the release
engineering processes are alike.
.0 releases go into their own branch and are aimed
mainly at early adopters. The branch then goes through a period
of stabilisation, and it is not until the
decides the demands to stability have been satisfied that
the branch becomes -STABLE and -CURRENT targets the next major
version. While this for the majority has been with .1 versions,
this is not a demand.
Most releases are made when a given date that has been deemed a
long enough time since the previous release comes. A target is
set for having major releases every 18 months and minor
releases every 4 months.
The user community has made it very clear that security and
stability cannot be sacrificed by self-imposed deadlines and
target release dates.
For slips of time not to become too long with regards to security
and stability issues,
extra discipline is required when committing changes to -STABLE.
Make release scheduleFeature freezeCode freezeMake branchRelease candidateStabilize release (loop back to
previous step as many times as necessary; when
release is considered stable, proceed with next
step)
Build packagesWarn mirrorsPublish releaseTools
The major support tools for supporting the development process are
Bugzilla, Mailman, and OpenSSH. These are externally
developed tools and are commonly used in the open source world.
Subversion (SVN)Subversion (SVN)
is a system to handle multiple versions of text files and
tracking who committed what changes and why. A project lives
within a repository and different versions are
considered different branches.
Bugzilla
Bugzilla is a maintenance database consisting of a set of tools to track bugs at a
central site. It supports the bug tracking process for sending
and handling bugs as well as querying and updating the database
and editing bug reports. The project uses its
web interface to send
Problem Reports to the
project's central Bugzilla server. The committers also have web and
command-line clients.
Mailman
Mailman is a program that automates the
management of mailing lists. The FreeBSD Project uses it to run
16 general lists, 60 technical lists, 4 limited lists and 5 lists
with SVN commit logs. It is
also used for many mailing lists set up and used by other people
and projects in the FreeBSD community. General lists are lists
for the general public, technical lists are mainly for the
development of specific areas of interest, and closed lists
are for internal communication not intended for the general
public. The majority of all the communication in the project goes
through these 85 lists
, Appendix C.
Pretty Good Privacy
Pretty Good Privacy, better known as PGP, is a cryptosystem
using a public key architecture to allow people to digitally
sign and/or encrypt information in order to ensure secure
communication between two parties. A signature is used when
sending information out to many recipients, enabling them to verify
that the information has not been tampered with before they
received it. In the FreeBSD Project this is the primary means of
ensuring that information has been written by the person who
claims to have written it, and not altered in transit.
Secure Shell
Secure Shell is a standard for securely logging into a remote system
and for executing commands on the remote system. It allows
other connections, called tunnels, to be established and
protected between the two involved systems. This standard
exists in two primary versions, and only version two is used
for the FreeBSD Project. The most common implementation of the
standard is OpenSSH that is a part of the project's main distribution.
Since its source is updated more often than FreeBSD releases,
the latest version is also available in the ports tree.
Sub-projects
Sub-projects are formed to reduce the amount of communication
needed to coordinate the group of developers. When a problem
area is sufficiently isolated, most communication would be
within the group focusing on the problem, requiring less
communication with the groups they communicate with than were
the group not isolated.
The Ports Subproject
A port is a set of meta-data and patches that
are needed to fetch, compile and install correctly an external piece of
software on a FreeBSD system. The amount of ports has grown
at a tremendous rate, as shown by the following figure.
shows the number of ports
available to FreeBSD in the period 1995 to 2008. It looks
like the curve has first grown exponentially, and then
from the middle of 2001 to the middle of 2007 grown
linearly at a rate of about 2000 ports/year, before its
growth rate gets lower.
Approximate dates each multiple of 1000 ports is reached
Number of portsApproximate date1000Late 19972000Late 19983000Early 20004000Late 20005000Mid 200160004th quarter of 20017000Mid 200280004th quarter of 20029000Mid 200310000End of 200311000Mid 200412000End of 200413000Mid 200514000Early 200615000Mid 2006160003rd quarter 2006170002nd quarter 2007
Approximate number of ports at the start of each year
YearApproximate number of ports199510019963001997700199812001999200020002900200143002002620020038100200410050200512100200614000200716200200817900
As the external software described by the port often is under
continued development, the amount of work required to maintain
the ports is already large, and increasing. This has led to
the ports part of the FreeBSD project gaining a more empowered
structure, and is more and more becoming a sub-project of the
FreeBSD project.
Ports has its own core team with the
as its leader, and this
team can appoint committers without FreeBSD Core's
approval. Unlike in the FreeBSD Project, where a lot of maintenance
frequently is rewarded with a commit bit, the ports sub-project
contains many active maintainers that are not committers.
Unlike the main project, the ports tree is not branched. Every
release of FreeBSD follows the current ports collection and has thus
available updated information on where to find programs and
how to build them. This, however, means that a port that makes
dependencies on the system may need to have variations
depending on what version of FreeBSD it runs on.
With an unbranched ports repository
it is not possible to guarantee that any port
will run on anything other than -CURRENT and -STABLE, in
particular older, minor releases. There is neither the infrastructure
nor volunteer time needed to guarantee this.
For efficiency of communication, teams depending on Ports,
such as the release engineering team, have their own ports liaisons.
The FreeBSD Documentation Project
The FreeBSD Documentation project was started January 1995. From
the initial group of a project leader, four team leaders and 16
members, they are now a total of 44 committers. The
documentation mailing list has just under 300 members,
indicating that there is quite a large community around it.
The goal of the Documentation project is to provide good and
useful documentation of the FreeBSD project, thus making it
easier for new users to get familiar with the system and
detailing advanced features for the users.
The main tasks in the Documentation project are to work on
current projects in the FreeBSD Documentation Set,
and translate the documentation to other languages.
Like the FreeBSD Project, documentation is split in the same
branches. This is done so that there is always an updated
version of the documentation for each version. Only
documentation errors are corrected in the security branches.
Like the ports sub-project, the Documentation project can
appoint documentation committers without FreeBSD Core's approval.
.
The Documentation project has a
primer. This is used both to
introduce new project members to the standard tools and
syntaxes and to act as a reference when working on the project.
ReferencesFrederick P.Brooks19751995Pearson Education Limited0201835959Addison-Wesley Pub CoThe Mythical Man-MonthEssays on Software Engineering, Anniversary Edition (2nd Edition)NiklasSaers2003A project model for the FreeBSD ProjectCandidatus Scientiarum thesishttp://niklas.saers.com/thesisNielsJørgensen2001Putting it All in the TrunkIncremental Software Development in the FreeBSD Open Source Projecthttp://www.dat.ruc.dk/~nielsj/research/papers/freebsd.pdfProject Management Institute19962000Project Management Institute1-880410-23-0Project Management InstituteNewtown SquarePennsylvaniaUSAPMBOK GuideA Guide to the Project Management Body of Knowledge,
2000 Edition2002The FreeBSD ProjectCore Bylawshttps://www.freebsd.org/internal/bylaws.html2002The FreeBSD Documentation ProjectFreeBSD Developer's Handbookhttps://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/2002The FreeBSD ProjectCore team election 2002http://election.uk.freebsd.org/candidates.htmlDag-ErlingSmørgravHitenPandya2002The FreeBSD Documentation ProjectThe FreeBSD Documentation ProjectProblem Report Handling Guidelineshttps://www.freebsd.org/doc/en/articles/pr-guidelines/article.htmlDag-ErlingSmørgrav2002The FreeBSD Documentation ProjectThe FreeBSD Documentation ProjectWriting FreeBSD Problem Reportshttps://www.freebsd.org/doc/en/articles/problem-reports/article.html2001The FreeBSD Documentation ProjectThe FreeBSD Documentation ProjectCommitters Guidehttps://www.freebsd.org/doc/en/articles/committers-guide/article.htmlMurrayStokely2002The FreeBSD Documentation ProjectThe FreeBSD Documentation ProjectFreeBSD Release Engineeringhttps://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.htmlThe FreeBSD Documentation ProjectFreeBSD Handbookhttps://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook2002The FreeBSD Documentation ProjectThe FreeBSD Documentation ProjectContributors to FreeBSDhttps://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/article.html2002The FreeBSD ProjectThe FreeBSD ProjectCore team elections 2002http://election.uk.freebsd.org2002The FreeBSD ProjectThe FreeBSD ProjectCommit Bit Expiration Policy2002/04/06 15:35:30https://www.freebsd.org/internal/expire-bits.html2002The FreeBSD ProjectThe FreeBSD ProjectNew Account Creation Procedure2002/08/19 17:11:27https://www.freebsd.org/internal/new-account.html2002The FreeBSD Documentation ProjectThe FreeBSD Documentation ProjectFreeBSD DocEng Team Charter2003/03/16 12:17https://www.freebsd.org/internal/doceng.htmlGregLehey2002Greg LeheyGreg LeheyTwo years in the trenchesThe evolution of a software projecthttp://www.lemis.com/grog/In-the-trenches.pdf
Index: head/en_US.ISO8859-1/books/handbook/introduction/chapter.xml
===================================================================
--- head/en_US.ISO8859-1/books/handbook/introduction/chapter.xml (revision 54305)
+++ head/en_US.ISO8859-1/books/handbook/introduction/chapter.xml (revision 54306)
@@ -1,1162 +1,1162 @@
IntroductionJimMockRestructured, reorganized, and parts rewritten
by SynopsisThank you for your interest in &os;! The following chapter
covers various aspects of the &os; Project, such as its
history, goals, development model, and so on.After reading this chapter you will know:How &os; relates to other computer operating
systems.The history of the &os; Project.The goals of the &os; Project.The basics of the &os; open-source development
model.And of course: where the name &os; comes
from.Welcome to &os;!4.4BSD-Lite&os; is an Open Source, standards-compliant Unix-like
operating system for x86 (both 32 and 64 bit), &arm;, AArch64,
&risc-v;, &mips;, &power;, &powerpc;, and Sun &ultrasparc;
computers. It provides all the features that are
nowadays taken for granted, such as preemptive multitasking,
memory protection, virtual memory, multi-user facilities, SMP
support, all the Open Source development tools for different
languages and frameworks, and desktop features centered around
X Window System, KDE, or GNOME. Its particular strengths
are:Liberal Open Source license,
which grants you rights to freely modify and extend
its source code and incorporate it in both Open Source
projects and closed products without imposing
restrictions typical to copyleft licenses, as well
as avoiding potential license incompatibility
problems.Strong TCP/IP networkingTCP/IP
networking - &os;
implements industry standard protocols with ever
increasing performance and scalability. This makes
it a good match in both server, and routing/firewalling
roles - and indeed many companies and vendors use it
precisely for that purpose.Fully integrated OpenZFS support,
including root-on-ZFS, ZFS Boot Environments, fault
management, administrative delegation, support for jails,
&os; specific documentation, and system installer
support.Extensive security features,
from the Mandatory Access Control framework to Capsicum
capability and sandbox mechanisms.Over 30 thousand prebuilt
packages for all supported architectures,
and the Ports Collection which makes it easy to build your
own, customized ones.Documentation - in addition
to Handbook and books from different authors that cover
topics ranging from system administration to kernel
internals, there are also the &man.man.1; pages, not only
for userspace daemons, utilities, and configuration files,
but also for kernel driver APIs (section 9) and individual
drivers (section 4).Simple and consistent repository structure
and build system - &os; uses a single
repository for all of its components, both kernel and
userspace. This, along with an unified and easy to
customize build system and a well thought out development
process makes it easy to integrate &os; with build
infrastructure for your own product.Staying true to Unix philosophy,
preferring composability instead of monolithic all
in one daemons with hardcoded behavior.binary compatibilityLinuxBinary compatibility with Linux,
which makes it possible to run many Linux binaries without
the need for virtualisation.&os; is based on the 4.4BSD-Lite4.4BSD-Lite release from Computer
Systems Research Group (CSRG)Computer Systems Research Group (CSRG) at the University of California at Berkeley, and
carries on the distinguished tradition of BSD systems
development. In addition to the fine work provided by CSRG,
the &os; Project has put in many thousands of man-hours
into extending the functionality and fine-tuning the system
for maximum performance and reliability
in real-life load situations. &os; offers performance and
reliability on par with other Open Source and commercial
offerings, combined with cutting-edge features not available
anywhere else.What Can &os; Do?The applications to which &os; can be put are truly
limited only by your own imagination. From software
development to factory automation, inventory control to
azimuth correction of remote satellite antennae; if it can be
done with a commercial &unix; product then it is more than
likely that you can do it with &os; too! &os; also benefits
significantly from literally thousands of high quality
applications developed by research centers and universities
around the world, often available at little to no cost.Because the source code for &os; itself is freely
available, the system can also be customized to an almost
unheard of degree for special applications or projects, and in
ways not generally possible with operating systems from most
major commercial vendors. Here is just a sampling of some of
the applications in which people are currently using
&os;:Internet Services: The robust
TCP/IP networking built into &os; makes it an ideal
platform for a variety of Internet services such
as:Web serversIPv4 and IPv6 routingFirewallsfirewall
and NATNAT
(IP masquerading) gatewaysFTP serversFTP serverselectronic mailemailemail
Email serversAnd more...Education: Are you a student of
computer science or a related engineering field? There
is no better way of learning about operating systems,
computer architecture and networking than the hands on,
under the hood experience that &os; can provide. A number
of freely available CAD, mathematical and graphic design
packages also make it highly useful to those whose primary
interest in a computer is to get
other work done!Research: With source code for
the entire system available, &os; is an excellent platform
for research in operating systems as well as other
branches of computer science. &os;'s freely available
nature also makes it possible for remote groups to
collaborate on ideas or shared development without having
to worry about special licensing agreements or limitations
on what may be discussed in open forums.Networking: Need a new
router?router A name server (DNS)?DNS Server A firewall to keep people out of your
internal network? &os; can easily turn that unused
PC sitting in the corner into an advanced router with
sophisticated packet-filtering capabilities.Embedded: &os; makes an
excellent platform to build embedded systems upon.
embedded
With support for the &arm;, &mips; and &powerpc;
platforms, coupled with a robust network stack, cutting
edge features and the permissive BSD
license &os; makes an excellent foundation for
building embedded routers, firewalls, and other
devices.X Window SystemGNOMEKDEDesktop: &os; makes a
fine choice for an inexpensive desktop solution
using the freely available X11 server.
&os; offers a choice from many open-source desktop
environments, including the standard
GNOME and
KDE graphical user interfaces.
&os; can even boot diskless from
a central server, making individual workstations
even cheaper and easier to administer.Software Development: The basic
&os; system comes with a full suite of development
tools including a full
C/C++Compiler
compiler and debugger suite.
Support for many other languages are also available
through the ports and packages collection.&os; is available to download free of charge, or can be
obtained on either CD-ROM or DVD. Please see
for more information about obtaining
&os;.Who Uses &os;?userslarge sites running &os;&os; has been known for its web serving capabilities -
sites that run on &os; include
Hacker News,
Netcraft,
NetEase,
Netflix,
Sina,
Sony Japan,
Rambler,
Yahoo!, and
Yandex.
&os;'s advanced features, proven security, predictable
release cycle, and permissive license have led to its use as a
platform for building many commercial and open source
appliances, devices, and products. Many of the world's
largest IT companies use &os;:Apache
Apache - The Apache Software Foundation runs most of
its public facing infrastructure, including possibly one
of the largest SVN repositories in the world with over 1.4
million commits, on &os;.Apple
Apple - OS X borrows heavily from &os; for the
network stack, virtual file system, and many userland
components. Apple iOS also contains elements borrowed
from &os;.Cisco
Cisco - IronPort network security and anti-spam
appliances run a modified &os; kernel.Citrix
Citrix - The NetScaler line of security appliances
provide layer 4-7 load balancing, content caching,
application firewall, secure VPN, and mobile cloud network
access, along with the power of a &os; shell.Dell EMC Isilon
Isilon - Isilon's enterprise storage appliances
are based on &os;. The extremely liberal &os; license
allowed Isilon to integrate their intellectual property
throughout the kernel and focus on building their product
instead of an operating system.Quest
KACE
Quest KACE - The KACE system management appliances run
&os; because of its reliability, scalability, and the
community that supports its continued development.iXsystems
iXsystems - The TrueNAS line of unified storage
appliances is based on &os;. In addition to their
commercial products, iXsystems also manages development of
the open source projects TrueOS and FreeNAS.Juniper
Juniper - The JunOS operating system that powers all
Juniper networking gear (including routers, switches,
security, and networking appliances) is based on &os;.
Juniper is one of many vendors that showcases the
symbiotic relationship between the project and vendors of
commercial products. Improvements generated at Juniper
are upstreamed into &os; to reduce the complexity of
integrating new features from &os; back into JunOS in the
future.McAfee
McAfee - SecurOS, the basis of McAfee enterprise
firewall products including Sidewinder is based on
&os;.NetApp
NetApp - The Data ONTAP GX line of storage
appliances are based on &os;. In addition, NetApp has
contributed back many features, including the new BSD
licensed hypervisor, bhyve.Netflix
Netflix - The OpenConnect appliance that Netflix
uses to stream movies to its customers is based on &os;.
Netflix has made extensive contributions to the codebase
and works to maintain a zero delta from mainline &os;.
Netflix OpenConnect appliances are responsible for
delivering more than 32% of all Internet traffic in North
America.Sandvine
Sandvine - Sandvine uses &os; as the basis of their
high performance real-time network processing platforms
that make up their intelligent network policy control
products.Sony
Sony - The PlayStation 4 gaming console runs a
modified version of &os;.Sophos
Sophos - The Sophos Email Appliance product is based
on a hardened &os; and scans inbound mail for spam and
viruses, while also monitoring outbound mail for malware
as well as the accidental loss of sensitive
information.Spectra
Logic
Spectra Logic - The nTier line of archive grade storage
appliances run &os; and OpenZFS.Stormshield
Stormshield - Stormshield Network Security appliances
are based on a hardened version of &os;. The BSD license
allows them to integrate their own intellectual property with
the system while returning a great deal of interesting
development to the community.The Weather
Channel
The Weather Channel - The IntelliStar appliance that is installed
at each local cable provider's headend and is responsible
for injecting local weather forecasts into the cable TV
network's programming runs &os;.Verisign
Verisign - Verisign is responsible for operating the
.com and .net root domain registries as well as the
accompanying DNS infrastructure. They rely on a number of
different network operating systems including &os; to
ensure there is no common point of failure in their
infrastructure.Voxer
Voxer - Voxer powers their mobile voice messaging
platform with ZFS on &os;. Voxer switched from a Solaris
derivative to &os; because of its superior documentation,
larger and more active community, and more developer
friendly environment. In addition to critical features
like ZFS and DTrace, &os; also offers
TRIM support for ZFS.Fudo
Security
Fudo Security - The FUDO security appliance allows
enterprises to monitor, control, record, and audit
contractors and administrators who work on their systems.
Based on all of the best security features of &os;
including ZFS, GELI, Capsicum, HAST, and
auditdistd.&os; has also spawned a number of related open source
projects:BSD
Router
BSD Router - A &os; based replacement for large
enterprise routers designed to run on standard PC
hardware.FreeNAS
FreeNAS - A customized &os; designed to be used as a
network file server appliance. Provides a python based
web interface to simplify the management of both the UFS
and ZFS file systems. Includes support for NFS, SMB/CIFS,
AFP, FTP, and iSCSI. Includes an extensible plugin system
based on &os; jails.GhostBSD
GhostBSD - is derived from &os;, uses the GTK
environment to provide a beautiful looks and comfortable
experience on the modern BSD platform offering a natural
and native &unix; work environment.mfsBSD
mfsBSD - A toolkit for building a &os; system image
that runs entirely from memory.NAS4Free
NAS4Free - A file server distribution based on &os;
with a PHP powered web interface.OPNSense
OPNsense - OPNsense is an open source, easy-to-use and
easy-to-build FreeBSD based firewall and routing platform.
OPNsense includes most of the features available in
expensive commercial firewalls, and more in many cases.
It brings the rich feature set of commercial offerings
with the benefits of open and verifiable sources.TrueOS
TrueOS - TrueOS is based on the legendary security
and stability of &os;. TrueOS follows &os;-CURRENT, with
the latest drivers, security updates, and packages
available.FuryBSD
FuryBSD - is a brand new, open source &os; desktop.
FuryBSD pays homage to desktop BSD projects of the past
like PC-BSD and TrueOS with its graphical interface and
adds additional tools like a live, hybrid USB/DVD image.
FuryBSD is completely free to use and distributed under
the BSD license.MidnightBSD
MidnightBSD - is a &os; derived operating system
developed with desktop users in mind. It includes all the
software you'd expect for your daily tasks: mail,
web browsing, word processing, gaming, and much
more.pfSense
pfSense - A firewall distribution based on &os; with
a huge array of features and extensive IPv6
support.ZRouter
ZRouter - An open source alternative firmware for
embedded devices based on &os;. Designed to replace the
proprietary firmware on off-the-shelf routers.A list of
testimonials from companies basing their products and
services on &os; can be found at the FreeBSD
Foundation website. Wikipedia also maintains a list
of products based on &os;.About the &os; ProjectThe following section provides some background information
on the project, including a brief history, project goals, and
the development model of the project.A Brief History of &os;386BSD PatchkitHubbard, JordanWilliams, NateGrimes, RodFreeBSD ProjecthistoryThe &os; Project had its genesis in the early part
of 1993, partially as the brainchild of the Unofficial
386BSDPatchkit's last 3 coordinators: Nate Williams,
Rod Grimes and Jordan Hubbard.386BSDThe original goal was to produce an intermediate snapshot
of 386BSD in order to fix a number of problems that
the patchkit mechanism was just not capable of solving. The
early working title for the project was 386BSD 0.5 or 386BSD
Interim in reference of that fact.Jolitz, Bill386BSD was Bill Jolitz's operating system, which had been
up to that point suffering rather severely from almost a
year's worth of neglect. As the patchkit swelled ever more
uncomfortably with each passing day, they decided to assist
Bill by providing this interim cleanup
snapshot. Those plans came to a rude halt when Bill Jolitz
suddenly decided to withdraw his sanction from the project
without any clear indication of what would be done
instead.Greenman, DavidWalnut Creek CDROMThe trio thought that the goal remained worthwhile, even
without Bill's support, and so they adopted the name "&os;"
coined by David Greenman. The initial objectives were set
after consulting with the system's current users and, once it
became clear that the project was on the road to perhaps even
becoming a reality, Jordan contacted Walnut Creek CDROM with
an eye toward improving &os;'s distribution channels for those
many unfortunates without easy access to the Internet. Walnut
Creek CDROM not only supported the idea of distributing &os;
on CD but also went so far as to provide the project with a
machine to work on and a fast Internet connection. Without
Walnut Creek CDROM's almost unprecedented degree of faith in
what was, at the time, a completely unknown project, it is
quite unlikely that &os; would have gotten as far, as fast, as
it has today.4.3BSD-LiteNet/2U.C. Berkeley386BSDFree Software
FoundationThe first CD-ROM (and general net-wide) distribution was
&os; 1.0, released in December of 1993. This was based
on the 4.3BSD-Lite (Net/2) tape from U.C.
Berkeley, with many components also provided by 386BSD and the
Free Software Foundation. It was a fairly reasonable success
for a first offering, and they followed it with the highly
successful &os; 1.1 release in May of 1994.NovellU.C. BerkeleyNet/2AT&TAround this time, some rather unexpected storm clouds
formed on the horizon as Novell and U.C. Berkeley settled
their long-running lawsuit over the legal status of the
Berkeley Net/2 tape. A condition of that settlement was U.C.
Berkeley's concession that large parts of Net/2 were
encumbered code and the property of Novell, who
had in turn acquired it from AT&T some time previously.
What Berkeley got in return was Novell's
blessing that the 4.4BSD-Lite release, when
it was finally released, would be declared unencumbered and
all existing Net/2 users would be strongly encouraged to
switch. This included &os;, and the project was given until
the end of July 1994 to stop shipping its own Net/2 based
product. Under the terms of that agreement, the project was
allowed one last release before the deadline, that release
being &os; 1.1.5.1.&os; then set about the arduous task of literally
re-inventing itself from a completely new and rather
incomplete set of 4.4BSD-Lite bits. The Lite
releases were light in part because Berkeley's CSRG had
removed large chunks of code required for actually
constructing a bootable running system (due to various legal
requirements) and the fact that the Intel port of 4.4 was
highly incomplete. It took the project until November of 1994
to make this transition, and in December it released
&os; 2.0 to the world. Despite being still more than a
little rough around the edges, the release was a significant
success and was followed by the more robust and easier to
install &os; 2.0.5 release in June of 1995.Since that time, &os; has made a series of releases each
time improving the stability, speed, and feature set of the
previous version.For now, long-term development projects continue to take
place in the 10.X-CURRENT (trunk) branch, and snapshot
releases of 10.X are continually made available from the
snapshot server as work progresses.&os; Project GoalsJordanHubbardContributed by FreeBSD ProjectgoalsThe goals of the &os; Project are to provide software
that may be used for any purpose and without strings attached.
Many of us have a significant investment in the code (and
project) and would certainly not mind a little financial
compensation now and then, but we are definitely not prepared
to insist on it. We believe that our first and foremost
mission is to provide code to any and all
comers, and for whatever purpose, so that the code gets the
widest possible use and provides the widest possible benefit.
This is, I believe, one of the most fundamental goals of Free
Software and one that we enthusiastically support.GNU General Public License (GPL)GNU Lesser General Public License (LGPL)BSD CopyrightThat code in our source tree which falls under the GNU
General Public License (GPL) or Library General Public License
(LGPL) comes with slightly more strings attached, though at
least on the side of enforced access rather than the usual
opposite. Due to the additional complexities that can evolve
in the commercial use of GPL software we do, however, prefer
software submitted under the more relaxed BSD license when
it is a reasonable option to do so.The &os; Development ModelSatoshiAsamiContributed by FreeBSD Projectdevelopment modelThe development of &os; is a very open and flexible
process, being literally built from the contributions of
thousands of people around the world, as can be seen from our
list
of contributors. &os;'s development infrastructure
allow these thousands of contributors to collaborate over the
Internet. We are constantly on the lookout for new developers
and ideas, and those interested in becoming more closely
involved with the project need simply contact us at the
&a.hackers;. The &a.announce; is also available to those
wishing to make other &os; users aware of major areas of
work.Useful things to know about the &os; Project and its
development process, whether working independently or in close
cooperation:The SVN repositoriesCVSCVS RepositoryConcurrent Versions SystemCVSSubversionSubversion RepositorySVNSubversion
For several years, the central source tree for &os;
was maintained by
CVS
(Concurrent Versions System), a freely available source
code control tool. In June 2008, the Project switched
to using SVN
(Subversion). The switch was deemed necessary, as the
technical limitations imposed by
CVS were becoming obvious due
to the rapid expansion of the source tree and the amount
of history already stored. The Documentation Project
and Ports Collection repositories also moved from
CVS to
SVN in May 2012 and July
2012, respectively. Please refer to the Obtaining the Source
section for more information on obtaining the
&os; src/ repository and Using the Ports
Collection for details on obtaining the &os;
Ports Collection.The committers listThe committerscommitters are the people who have
write access to the Subversion
tree, and are authorized to make modifications to the
&os; source (the term committer comes
from commit, the source control
command which is used to bring new changes into the
repository). Anyone can submit a bug to the Bug
Database. Before submitting a bug report, the
&os; mailing lists, IRC channels, or forums can be used to
help verify that an issue is actually a bug.The FreeBSD core teamThe &os; core teamcore team would be equivalent to the board of
directors if the &os; Project were a company. The
primary task of the core team is to make sure the
project, as a whole, is in good shape and is heading in
the right directions. Inviting dedicated and
responsible developers to join our group of committers
is one of the functions of the core team, as is the
recruitment of new core team members as others move on.
The current core team was elected from a pool of
- committer candidates in July 2018. Elections are held
+ committer candidates in June 2020. Elections are held
every 2 years.Like most developers, most members of the
core team are also volunteers when
it comes to &os; development and do not benefit from
the project financially, so commitment
should also not be misconstrued as meaning
guaranteed support. The
board of directors analogy above is not
very accurate, and it may be more suitable to say that
these are the people who gave up their lives in favor
of &os; against their better judgement!Outside contributorsLast, but definitely not least, the largest group of
developers are the users themselves who provide feedback
and bug fixes to us on an almost constant basis. The
primary way of keeping in touch with &os;'s more
non-centralized development is to subscribe to the
&a.hackers; where such things are discussed. See
for more information about
the various &os; mailing lists.The
&os; Contributors Listcontributors is a long and growing one, so why not join
it by contributing something back to &os; today?Providing code is not the only way of contributing
to the project; for a more complete list of things that
need doing, please refer to the &os; Project
web site.In summary, our development model is organized as a loose
set of concentric circles. The centralized model is designed
for the convenience of the users of &os;,
who are provided with an easy way of tracking one central code
base, not to keep potential contributors out! Our desire is to
present a stable operating system with a large set of coherent
application programs that the
users can easily install and use — this model works very
well in accomplishing that.All we ask of those who would join us as &os; developers
is some of the same dedication its current people have to its
continued success!Third Party ProgramsIn addition to the base distributions, &os; offers a
ported software collection with thousands of commonly
sought-after programs. At the time of this writing, there
were over &os.numports; ports! The list of ports ranges from
http servers, to games, languages, editors, and almost
everything in between. The entire Ports Collection requires
approximately &ports.size;. To compile a port, you simply
change to the directory of the program you wish to install,
type make install, and let the system do
the rest. The full original distribution for each port you
build is retrieved dynamically so you need only enough disk
space to build the ports you want. Almost every port is also
provided as a pre-compiled package, which can
be installed with a simple command
(pkg install) by those who do not wish to
compile their own ports from source. More information on
packages and ports can be found in
.Additional DocumentationAll supported &os; versions provide an option in the
installer to
install additional documentation under
/usr/local/share/doc/freebsd during the
initial system setup. Documentation may also be installed at
any later time using packages as described in
. You may view the
locally installed manuals with any HTML capable browser using
the following URLs:The FreeBSD Handbook/usr/local/share/doc/freebsd/handbook/index.htmlThe FreeBSD FAQ/usr/local/share/doc/freebsd/faq/index.htmlYou can also view the master (and most frequently updated)
copies at https://www.FreeBSD.org/.
Index: head/en_US.ISO8859-1/htdocs/administration.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/administration.xml (revision 54305)
+++ head/en_US.ISO8859-1/htdocs/administration.xml (revision 54306)
@@ -1,560 +1,560 @@
]>
&title;$FreeBSD$
Introduction
This page lists teams, groups and individuals within the
FreeBSD project with designated project roles and areas of
responsibility, along with brief descriptions and contact
information.
The FreeBSD Core Team constitutes the project's "Board of Directors",
responsible for deciding the project's overall goals and direction as
well as managing specific areas of the FreeBSD project landscape. The
Core Team is elected by the active developers in the project.
-
&a.allanjude.email; (Clusteradm Liaison)
-
&a.bcr.email; (Foundation Liaison)
-
&a.brooks.email; (Security Team Liaison)
-
&a.hrs.email; (Doceng Team Liaison)
-
&a.jeff.email;
-
&a.jhb.email; (Bugmeister and Release Engineering Team Liaison)
-
&a.kmoore.email;
-
&a.seanc.email; (CI and Portmgr Team Liaison)
-
&a.imp.email; (Code-of-Conduct Committee Liaison)
+
&a.bapt.email; (Clusteradm Liaison)
+
&a.emaste.email; (GIT Transition WG and Security Team Liason)
+
&a.gnn.email; (Foundation Liaison)
+
&a.hrs.email; (Code-of-Conduct Committee Liaison)
+
&a.kevans.email; (Portmgr Team Liaison)
+
&a.markj.email; (Bugmeister and CI Team Liaison)
+
&a.scottl.email; (Release Engineering Team Liaison)
The FreeBSD Documentation Engineering Team is responsible for
defining and following up documentation goals for the committers
in the Documentation project. The doceng team charter
describes the duties and responsibilities of the Documentation
Engineering Team in greater detail.
The primary responsibility of the FreeBSD Port Management Team is to
ensure that the FreeBSD Ports Developer community provides a ports
collection that is functional, stable, up-to-date and full-featured.
Its secondary responsibility is to coordinate among the committers
and developers who work on it. The portmgr team charter
describes the duties and responsibilities of the Port Management
Team in greater detail.
&a.adamw.email;
&a.antoine.email;
&a.bapt.email; (Core Team Liaison)
&a.bdrewery.email; (Release Engineering Team Liaison)
&a.mat.email; (Cluster Administration Team Liaison)
The primary responsibility of the FreeBSD Port Security Team is
to provide rapid response to security incidents that affects the
FreeBSD ports collection and protect the FreeBSD user community
by keeping the community informed of bugs, exploits, popular
attacks, and other risks. More details are available on the
Wiki
page.
The Primary Release Engineering Team is responsible for setting and
publishing release schedules for official project releases of FreeBSD,
announcing code freezes and maintaining releng/* branches,
among other things. The
release engineering team charter
describes the duties and responsibilities of the Primary Release
Engineering Team in greater detail.
The FreeBSD Donations Team is responsible for responding to donations
offers, establishing donation guidelines and procedures, and coordinating
donation offers with the FreeBSD developer community. A more detailed
description of the duties of the Donations Team is available on the FreeBSD Donations Liaison page.
The FreeBSD Security Team (headed by the Security Officer) is
responsible for keeping the community aware of bugs, exploits and
security risks affecting the FreeBSD src and ports trees, and to
promote and distribute information needed to safely run FreeBSD
systems. Furthermore, it is responsible for resolving software
bugs affecting the security of FreeBSD and issuing security
advisories. The FreeBSD
Security Officer Charter describes the duties and
responsibilities of the Security Officer in greater detail.
&a.gordon.email; (Officer)
&a.delphij.email; (Officer Emeritus, Release Engineering Team
Liaison)
&a.des.email; (Officer Emeritus)
&a.gjb.email; (Cluster Administrators Team Liaison)
Vendor Relations is responsible for handling email
from hardware and software vendors. Email sent to Vendor
Relations is forwarded to the &os; Core Team in addition
to the &os; Foundation.
The &os; Core Team Secretary is a non-voting member of the Core Team,
responsible for documenting the work done by core, keeping track of the core
agenda, contacting non-core members on behalf of core, sending mail to core,
and interfacing with the admin team for committer/account approval. The Core
Team Secretary is also responsible for writing and sending out monthly status
reports to the &os; Developer community, containing a summary of core's latest
decisions and actions.
The FreeBSD Documentation Engineering Team Secretary is a non-voting
member of the Documentation Engineering Team, responsible for documenting
the work done by doceng, keeping track of voting procedures, and to be an
interface to the other teams, especially the admin and Core teams.
The FreeBSD Port Management Team Secretary is a non-voting member of the
Port Management Team, responsible for documenting the work done by portmgr,
keeping track of voting procedures, and to be an interface to the other
teams, especially the admin and Core teams. The Port Management Team
Secretary is also responsible for writing and sending out monthly status
reports to the FreeBSD Developer community, containing a summary of
portmgr's latest decisions and actions.
The Accounts Team is responsible for setting up accounts for new
committers in the project. Requests for new accounts will not be
acted upon without the proper approval from the appropriate entity.
The Bugmeisters are responsible for ensuring that the problem report
software is in working order, that the entries are correctly categorised
and that there are no invalid entries.
The Cluster Administrators consists of the people responsible for
maintaing the machines and services that the project relies on for its
distributed work and communication. Issues concerning the projects
infrastructure or setting up new machines should be directed to them.
This team is led by the lead cluster administrator whose duties and
responsbilities are described in the cluster administration charter
in greater detail.
The Forum Administrators maintain the &os; Project's Internet forum,
located at https://forums.freebsd.org/
and lead the group of moderators who work to ensure the relevance and quality of
the forum's content.
The Jenkins Administrators maintain the Continuous Integration and
testing infrastructure for The &os; Project. This includes maintaining
the Jenkins instance and the jobs that run builds and execute tests.
The FTP/WWW Mirror Site Coordinators coordinate all the FTP/WWW
mirror site administrators to ensure that they are distributing current
versions of the software, that they have the capacity to update
themselves when major updates are in progress, and making it easy for
the general public to find their closest FTP/WWW mirror.
E-mail to the Mirror Site Coordinators is currently forwarded to
the Cluster Administrators with the
addition of:
The Phabricator Administrators are responsible for maintaining the &os;'s
instance of the Phabricator on-line code review tool located at
https://reviews.freebsd.org/
&a.allanjude.email;
&a.bofh.email;
&a.eadler.email;
&a.emaste.email;
&a.jtl.email;
&a.lwhsu.email;
&a.mat.email;
&a.miwi.email;
&a.pi.email;
For any problems regarding Phabricator, please open a bug report
and select "Services" and then "Code Review".
The Postmaster Team is responsible for mail being correctly delivered
to the committers' email address, ensuring that the mailing lists work,
and should take measures against possible disruptions of project mail
services, such as having troll-, spam- and virus-filters.
The FreeBSD Webmaster Team is appointed by &os; Documentation Engineering Team,
and responsible for keeping the main FreeBSD web
sites up and running. This means web server configuration, CGI scripts,
fulltext and mailing list search. Anything web related, technical stuff
belongs to the scope of the Webmaster Team, excluding bugs in the
documentation.
Email to the Webmaster Team is currently forwarded to the Documentation Engineering team with the
addition of: