Wiki code for Glossary

Hide Line numbers
1: == Appendix A. Glossary ==
2: 
3:  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.
4: 
5: {{toc start="3" depth="3" numbered="false" scope="page"/}}
6: 
7: === ACR ===
8: 
9:  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>>devref_glossary#Hbrickify]] your system.
10: 
11: === ARC ===
12: 
13:  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.
14: 
15: === archives ===
16: 
17:  CPIO-format files used by [[BFU>>devref_glossary#HBFU]]. These contain all the ON binaries that are installed during the BFU.
18: 
19: === BFU ===
20: 
21:  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>>devref_glossary#HON]] [[consolidation>>devref_glossary#Hconsolidation]] 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>>devref_5]]. BFU is implemented by ’mkbfu’, ’makebfu’, ’cpiotranslate’, and bfu(1).
22: 
23: === binary patch ===
24: 
25:  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 are the reponsibility of distributions.
26: 
27: === brickify ===
28: 
29:  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.
30: 
31: === CTF ===
32: 
33:  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.
34: 
35: === consolidation ===
36: 
37:  A set of related software components developed and delivered together. An example is the [[ON>>devref_glossary#HON]] 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.
38: 
39: === gate ===
40: 
41:  The main or official [[workspace>>devref_glossary#Hworkspace]] for a [[project>>devref_glossary#Hproject]] or [[consolidation>>devref_glossary#Hconsolidation]]. 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>>devref_glossary#HWOS]], as appropriate. After completing implementation and review, a developer will [[putback>>devref_glossary#Hputback]] his or her changes to an appropriate gate. A gate is "golden source," a shared resource expected to be usable at all times.
42: 
43: === lint ===
44: 
45:  lint(1) is a utility used to perform various checks on source code. All new code in ON 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.
46: 
47: === Mercurial ===
48: 
49:  The Source Code Management (SCM) package that is currently used for [[ON>>devref_glossary#HON]] development, and one of the two SCM packages available on the opensolaris.org site. It is sometimes referred to as "hg" (the chemical symbol for mercury and the command name used for Mercurial operations). Additional information on using Mercurial with OpenSolaris is available on the [[OpenSolaris web site>>Community Group tools.hg_help]]. General information about Mercurial is available at the [[Mercurial web site>>http://www.selenic.com/mercurial]].
50: 
51: === Nevada ===
52: 
53:  Nevada is the code name for the development version of Solaris following Solaris 10. It is derived from the OpenSolaris code base and is distributed as Solaris Express.
54: 
55: === ON ===
56: 
57:  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.
58: 
59: === PIT ===
60: 
61:  Pre-Integration Tests. These are automated tests that are run prior to each biweekly build.
62: 
63: === Platinum Beta ===
64: 
65:  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.
66: 
67: === project ===
68: 
69:  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.
70: 
71: === putback ===
72: 
73:  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.
74: 
75: === RFE ===
76: 
77:  Request for Enhancement. (Feature request.)
78: 
79: === Solaris Next ===
80: 
81:  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>>devref_glossary#HNevada]] (Solaris 11).
82: 
83: === source patch ===
84: 
85:  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>>devref_glossary#Hbinarypatch]] above.
86: 
87: === suninstall ===
88: 
89:  The standard Solaris installer. A suninstall installation includes the full [[WOS>>devref_glossary#HWOS]] and is done from CD or network.
90: 
91: === SWAN ===
92: 
93:  The Sun Wide Area Network, Sun’s internal network.
94: 
95: === TeamWare ===
96: 
97:  The Source Code Management (SCM) software that was used at Sun for [[ON>>devref_glossary#HON]] development from the early 1990s until 2008. Sometimes abbreviated as "TW".
98: 
99: === Tonic ===
100: 
101:  Internal code name for the OpenSolaris program. The Tonic team did much of the initial analysis and planning for opening the Solaris code base. The team is currently responsible for the opensolaris.org website, tool work to support open development, and tool work to support the inclusion of third-party open source packages in OpenSolaris.
102: 
103: === UTS ===
104: 
105:  UNIX Time Sharing. The OpenSolaris kernel codebase.
106: 
107: === workspace ===
108: 
109:  A workspace includes a full source tree as well as metadata such as log files and version control information.
110: 
111: === WOS ===
112: 
113:  "Wad Of Stuff," referring to the integration of all consolidations that make up the Solaris binary distribution shipped to customers.
OpenSolaris

Top Menu

Wiki code for Glossary

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group on Pages
