Source string Read only

(itstool) path: figure/programlisting

Context English State
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
Setup processes that help in tracking the development of FreeBSD. For example:
Track FreeBSD source code
The project makes it easy to mirror its SVN repository using <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/committers-guide/article.html#svn-advanced-use-setting-up-svnsync"><application>svnsync</application></link>. Having the complete history of the source is useful when debugging complex problems and offers valuable insight into the intentions of the original developers. Use a capable source control system that allows you to easily merge changes between the upstream FreeBSD code base and your own in-house code.
<xref linkend="fig-svn-blame"/> shows a portion of an annotated listing of the file referenced by the change log in <xref linkend="fig-change-log"/>. The ancestry of each line of the source is clearly visible. Annotated listings showing the history of every file that is part of FreeBSD are <link xlink:href="">available on the web</link>.
An annotated source listing generated using <command>svn blame</command>


176410 bde 2008-02-19 07:42:46 -0800 (Tue, 19 Feb 2008) #include &lt;sys/cdefs.h&gt;
176410 bde 2008-02-19 07:42:46 -0800 (Tue, 19 Feb 2008) __FBSDID("$FreeBSD: head/en_US.ISO8859-1/articles/building-products/article.xml 54253 2020-06-14 08:10:06Z carlavilla $");
2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994)
2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) /* __ieee754_rem_pio2f(x,y)
8870 rgrimes 1995-05-29 22:51:47 -0700 (Mon, 29 May 1995) *
176552 bde 2008-02-25 05:33:20 -0800 (Mon, 25 Feb 2008) * return the remainder of x rem pi/2 in *y
176552 bde 2008-02-25 05:33:20 -0800 (Mon, 25 Feb 2008) * use double precision for everything except passing x
152535 bde 2005-11-16 18:20:04 -0800 (Wed, 16 Nov 2005) * use __kernel_rem_pio2() for large x
2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) */
2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994)
176465 bde 2008-02-22 07:55:14 -0800 (Fri, 22 Feb 2008) #include &lt;float.h&gt;
176465 bde 2008-02-22 07:55:14 -0800 (Fri, 22 Feb 2008)
2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) #include "math.h"

Use a gatekeeper
Appoint a <firstterm>gatekeeper</firstterm> to monitor FreeBSD development, to keep an eye out for changes that could potentially impact your products.
Report bugs upstream
If you notice bug in the FreeBSD code that you are using, file a <link xlink:href="">bug report</link>. This step helps ensure that you do not have to fix the bug the next time you take a code drop from upstream.
Leverage FreeBSD's release engineering efforts
Use code from a -STABLE development branch of FreeBSD. These development branches are formally supported by FreeBSD's release engineering and security teams and comprise of tested code.
Donate code to reduce costs
A major proportion of the costs associated with developing products is that of doing maintenance. By donating non-critical code to the project, you benefit by having your code see much wider exposure than it would otherwise get. This in turn leads to more bugs and security vulnerabilities being flushed out and performance anomalies being identified and fixed.
Get support effectively
For products with tight deadlines, it is recommended that you hire or enter into a consulting agreement with a developer or firm with FreeBSD experience. The <link xlink:href="">FreeBSD related employment mailing list</link> is a useful communication channel to find talent. The FreeBSD project maintains a <link xlink:href="@@URL_RELPREFIX@@/commercial/consult_bycat.html">gallery of consultants and consulting firms</link> undertaking FreeBSD work. The <link xlink:href="">BSD Certification Group</link> offers certification for all the major BSD derived OSes.
For less critical needs, you can ask for help on the <link xlink:href="">project mailing lists</link>. A useful guide to follow when asking for help is given in <citation>Ray2004</citation>.
Publicize your involvement
You are not required to publicize your use of FreeBSD, but doing so helps both your effort as well as that of the project.
Letting the FreeBSD community know that your company uses FreeBSD helps improve your chances of attracting high quality talent. A large roster of support for FreeBSD also means more mind share for it among developers. This in turn yields a healthier foundation for your future.
Support FreeBSD developers


User avatar None

New source string

FreeBSD Doc / articles_building-productsEnglish

New source string 3 months ago
Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks



English English
No related strings found in the glossary.

Source information

Source string comment

(itstool) path: figure/programlisting

no-wrap, read-only
Source string location
String age
3 months ago
Source string age
3 months ago
Translation file
articles/building-products.pot, string 122