This glossary lists terms which are in common use within Sun but may be unfamiliar to other Open Source and Free Software developers. While we expect OpenSolaris will in time develop its own unique nomenclature, you may see other community members, especially Sun engineers, using these terms.
Automatic Conflict Resolver. A tool to aid in the resolution of conflicts imposed by a BFU prior to completing the upgrade. Without ACR all conflicts must be resolved manually, this simply automates the proccess and as such reduces the chances of missed conflicts that could brickify your system.
Architecture Review Committee. A committee of engineers assembled to review and approve (or not) software architecture. Architectural issues generally include interface dependencies and user interface presentation.
CPIO-format files used by BFU. These contain all the ON binaries that are installed during the BFU.
Blindingly Fast Upgrade a.k.a. Bonwick/Faulkner Upgrade. This is a way to upgrade the subset of a system's binaries that are delivered by the ON consolidation that uses cpio(1) archives instead of packages to improve speed. This requires manual resolution of configuration file conflicts and can be hazardous; therefore it is recommended only for developers who have read and understand 5.3 Using BFU to Install ON. BFU is implemented by 'mkbfu', 'makebfu', 'cpiotranslate', and bfu(1).
Collection of updated binary objects distributed to customers other than when official releases are made. Binary patches may correct an urgent security problem or address a specific bug specific to a major customer. Binary patches will not be issued for OpenSolaris, since the sources will include all such fixes. Distributions may elect to issue binary patches.
To render a system unbootable or otherwise unusable (a brick). Causes can be hardware or software, but in this document it usually means improper installation or installation of broken bits; in these cases the term "warmbrick" is also used. Recovering from this condition usually entails booting from alternate media.
Compact ANSI-C Type Format. CTF is a debugging information format similar to a subset of DWARF or STABS, but more efficient. The information is used by mdb, dtrace, and other facilities within Solaris.
A set of related software components developed and delivered together. An example is the ON consolidation, which consists of the kernel, libraries, and basic utility and server programs in OpenSolaris. Other consolidations deliver the windowing system, development tools, application servers, and so on.
The main or official workspace for a project or consolidation. This workspace is managed by the gatekeeper for the project or consolidation, who performs regular builds, backs out incorrect or nonconforming changes, and is responsible for either integrating the sources into a parent gate or delivering regular builds to the WOS, as appropriate. After completing implementation and review, a developer will putback his or her changes to an appropriate gate. A gate is "golden source," a shared resource expected to be usable at all times.
lint(1) is a utility used to perform various checks on source code. All new code in OpenSolaris must be "lint-clean," meaning that lint's checks on the code do not result in any warnings. This process of checking with lint(1) is known as linting.
Nevada is the current (as of 2005) development version of Solaris following Solaris 10. OpenSolaris is based on the Solaris Nevada sources. The name Nevada was used instead of 10.1 or 11 because it was not yet known whether this will be a micro or minor release; the initial assumption was that it will be a micro release; therefore the RELEASE was 5.10.1. However, as of build 14, Nevada is now a Minor Release. See attributes(5) and 7.1.1 Interface Stability Taxonomy for more information about the difference between release types.
The consolidation which delivers the OpenSolaris kernel, filesystems, some drivers and other modules, basic commands, daemons and servers, libraries, and system headers. Also known as OS/Net or OS/Networking.
A Sun beta program for customers that are willing and able to run beta releases in production. These customers see features like ZFS months or years before anyone else.
A collection of features and/or bug fixes which is extensive enough to require its own implementation team, gate, and plans. Examples of projects are dtrace, Janus, and a port to a new hardware platform. Normal individual enhancements and bug fixes are self-contained and worked on by no more than one or two developers; these do not require the infrastructure associated with projects.
After all changes are checked in, tested, reviewed, and approved, a developer integrates his or her changes into an appropriate gate. The word putback is used to refer to the set of changes itself and the act of integrating it into the gate.
The generic term occasionally used to refer to a new development version of Solaris, before it is known what type of release it will be. As of early 2005, Solaris Next would refer to Nevada (Solaris 11).
A set of diffs which describes a source code change. Many Open Source development efforts refer to this simply as a patch; however, see also binary patch above.
The standard Solaris installer. A suninstall installation includes the full WOS and is done from CD or network.
The Source Code Management (SCM) software used internally at Sun for Solaris development, abbreviated as "TW".
A workspace includes a full source tree as well as metadata such as log files and version control information.