The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: formalpara/para
Context English State
Machine architectures are grouped into <quote>tiers</quote>; <firstterm>Tier 1</firstterm> architectures are fully supported by the project's release engineering and security teams, <firstterm>Tier 2</firstterm> architectures are supported on a best effort basis, and experimental architectures comprise <firstterm>Tier 3</firstterm>. The list of <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">supported architectures</link> is part of the FreeBSD documentation collection.
The release engineering team publishes a <link xlink:href="@@URL_RELPREFIX@@/releng/">road map</link> for future releases of FreeBSD on the project's web site. The dates laid down in the road map are not deadlines; FreeBSD is released when its code and documentation are ready.
FreeBSD's release engineering processes are described in <citation>RelEngDoc</citation>.
Collaborating with FreeBSD
Open-source projects like FreeBSD offer finished code of a very high quality.
While access to quality source code can reduce the cost of initial development, in the long-term the costs of managing change begin to dominate. As computing environments change over the years and new security vulnerabilities are discovered, your product too needs to change and adapt. Using open-source code is best viewed not as a one-off activity, but as an <emphasis>ongoing process</emphasis>. The best projects to collaborate with are the ones that are <emphasis>live</emphasis>; i.e., with an active community, clear goals and a transparent working style.
FreeBSD has an active developer community around it. At the time of writing there are many thousands of contributors from every populated continent in the world and over 300 individuals with write access to the project's source repositories.
The goals of the FreeBSD project are <citation>Hub1994</citation>:
To develop a high-quality operating system for popular computer hardware, and,
To make our work available to all under a liberal license.
FreeBSD enjoys an open and transparent working culture. Nearly all discussion in the project happens by email, on <link xlink:href="">public mailing lists</link> that are also archived for posterity. The project's policies are <link xlink:href="@@URL_RELPREFIX@@/internal/policies.html">documented</link> and maintained under revision control. Participation in the project is open to all.
Understanding FreeBSD culture
To be able to work effectively with the FreeBSD project, you need to understand the project's culture.
Volunteer driven projects operate under different rules than for-profit corporates. A common mistake that companies make when venturing into the open-source world is that of underplaying these differences.
Most contributions to FreeBSD are done voluntarily without monetary rewards entering the picture. The factors that motivate individuals are complex, ranging from altruism, to an interest in solving the kinds of problems that FreeBSD attempts to solve. In this environment, <quote>elegance is never optional</quote> <citation>Nor1993</citation>.
The Long Term View
FreeBSD's <link xlink:href="">source repository</link> contains a history of the project since its inception, and there are <link xlink:href="">CDROMs available</link> that contain earlier code from the CSRG.
FreeBSD traces its roots back nearly twenty years to the work of the Computer Science Research Group at the University of California Berkeley.<_:footnote-1/> A number of the original CSRG developers remain associated with the project.
The project values long-term perspectives <citation>Nor2001</citation>. A frequent acronym encountered in the project is <acronym>DTRT</acronym>, which stands for <quote>Do The Right Thing</quote>.
Development Processes
Computer programs are tools for communication: at one level programmers communicate their intentions using a precise notation to a tool (a compiler) that translates their instructions to executable code. At another level, the same notation is used for communication of intent between two programmers.
Formal specifications and design documents are seldom used in the project. Clear and well-written code and well-written change logs (<xref linkend="fig-change-log"/>) are used in their place. FreeBSD development happens by <quote>rough consensus and running code</quote> <citation>Carp1996</citation>.
A sample change log entry

r151864 | bde | 2005-10-29 09:34:50 -0700 (Sat, 29 Oct 2005) | 13 lines
Changed paths:
M /head/lib/msun/src/e_rem_pio2f.c

Use double precision to simplify and optimize arg reduction for small
and medium size args too: instead of conditionally subtracting a float
17+24, 17+17+24 or 17+17+17+24 bit approximation to pi/2, always
subtract a double 33+53 bit one. The float version is now closer to
the double version than to old versions of itself -- it uses the same
33+53 bit approximation as the simplest cases in the double version,
and where the float version had to switch to the slow general case at
|x| == 2^7*pi/2, it now switches at |x| == 2^19*pi/2 the same as the
double version.

This speeds up arg reduction by a factor of 2 for |x| between 3*pi/4 and
2^7*pi/4, and by a factor of 7 for |x| between 2^7*pi/4 and 2^19*pi/4.
Communication between programmers is enhanced by the use of a common coding standard <citerefentry><refentrytitle>style</refentrytitle><manvolnum>9</manvolnum></citerefentry>.
Communication Channels
FreeBSD's contributors are spread across the world. Email (and to a lesser extent, IRC) is the preferred means of communication in the project.
Best Practices for collaborating with the FreeBSD project
We now look at a few best practices for making the best use of FreeBSD in product development.
Plan for the long term


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: formalpara/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/building-products.pot, string 101