最終更新日 2005年11月7日 PDF版もあります。

OpenSolarisの開発プロセス

バージョン1 [ドラフト] - 現在、査読中です。英語は こちら です。コメントをg11n(hyphen)ja(hyphen)discuss@opensolaris.org までお送りください。

 John Beck (ジョン ベック)、Rich Teer (リッチ ティア)、Al Hopper (アル ホッパー)、 David Comay (デイビッド コーメイ)、Stephen Hahn (ステファン ハーン)、Ed Hunter (エド ハンター)、Joe Kowalski (ジョー コワルスキー)、Keith Wesolowski (キース ウェソロウスキー)、Casper Dik (キャスパー ディック)、Bill Sommerfeld (ビル サマーフェルド) 共著

概要。 この文書ではOpenSolarisの開発プロセスの目的や特徴などを大まかに説明します。特に、コラボレーションによる共同開発を進めるため、既存の開発プロセスで変えなければならない点を明確にします。これは、既存のSunのツールやプロセスを良く知っているかどうか、あるいはアクセス権があるかどうかに関係なく、OpenSolaris開発に参加する機会を、平等に、すべての貢献者に与えるためです。また、既存の技術水準を維持し、強化するためです。ここでは、意図的に実行の問題には触れていません。開発プロセスは、各プロセスのステップを実行する人、ツールおよびインフラストラクチャーを個々に選択する手順から独立したものだからです。

この文書について

 この文書は、一般的なものから特殊なものまで、さまざまな資料を系統的にまとめています。OpenSolarisとその開発プロセスを大まかに知りたいという方は、基本情報を読むだけでよいでしょう。それに続くセクションでは、開発プロセスの概要をステップごとに説明します。各セクションにはそれぞれのステップに関する詳細な情報を含む付録がついています。個々のステップの詳細およびそこで使うツールについては、OpenSolaris開発者ガイドをご覧ください。開発プロセスの説明はすべて、実装する人の視点で書かれていますが、他の役割を担っている個人の責任範囲についても書かれています。

用語集は、良く使われる用語の定義を一覧にしたものです。これらの用語は、ソフトウェアエンジニアリング業界やさまざまなオープンソースコミュニティーで、いろいろな使われ方をしています。定義もバラバラで、矛盾していることさえあります。この用語集にある用語は、このドキュメント内での一貫性を保つことを目的として定義されています。

 第1章「基本情報」は基本的な情報と、厳密かつ系統的な開発プロセスの論理的根拠を示します。その上で、OpenSolarisの共同開発という仕事の範囲と目的、この仕事とSolarisオペレーティングシステムの関係を大まかに説明します。また、OpenSolarisコードベースの長年に渡る開発のなかで確立された高度な技術設計とプロセスの基準を紹介します。この基準を満たすソフトウェアの設計と実装が、OpenSolaris開発の主な目的です。

 「基本情報」に続く第2章「リリース管理」では、OpenSolarisコードベースの管理に関わるプロセスを説明します。この章「リリース管理」には、リリース名の付け方、リリース番号の付け方、および変更管理のルールが含まれます。また、ブランチ管理の方法とリリース基準について、ソースコードの管理体制とは別に、独立したものとして説明します。

 第3章「開発プロセス」では、実装する人の立場から、プロセスの流れとその概要を説明します。このプロセスは、現在 Sun の Solaris 関連組織内で実践されているソフトウェア開発フレームワーク (SDF:Software Development Fremework) を厳密に反映しています。ただし、互いに継続的かつ直接的な連絡がない個人やチームの貢献を取り入れるため、多少 SDF を修正しています。これは、地理的にも、組織的にも分散している開発者のことを考慮して、この状況に適した開発プロセスを作り上げるためです。また貢献していただいたものの実装に関するテストと品質保証 (QA) についても詳しく説明します。

「付録」は、開発プロセスの各ステップについて詳しく説明しています。 このドキュメントの内容について詳細情報が欲しいと思ったときには、付録の中から探してみてください。

 また、一貫性のあるわかりやすい方法で、 ソフトウェア・ハードウェアの区別なく、個々のコンポーネントを 管理できなければなりません。

基本情報

 この章では、OpenSolarisとは何か、Sun Microsystems, IncのSolaris製品との関係、そして設計の原則を説明します。OpenSolaris に参加して、自分で記述したコードを OpenSolaris コンソリデーション (注) のリリースブランチに組み込む場合は、この設計原則に従ってください。 また、開発プロセスそのものを変更する際に適用される原則についても説明します。

OpenSolarisプロジェクト

 OpenSolarisプロジェクトとはなにか。

 OpenSolarisプロジェクトは、Solarisオペレーティングシステムのソースコードをベースにしたオープンソースプロジェクトです。オペレーティングシステム技術の開発と向上のために、Sunとその他の貢献者が出会い、共同作業を行うコミュニティー開発の現場です。OpenSolarisのソースコードにはさまざまな用途があります。たとえば、Solaris OS製品の今後のバージョン、他のオペレーティングシステムのプロジェクト、コミュニティーにとって興味深いサードパーティーの製品やディストリビューションのベースになります。OpenSolarisプロジェクトのスポンサーは現在Sun Microsystems, Inc.です。

 OpenSolarisプロジェクトは、現在Solaris OSとともに配布されているコアカーネル、ライブラリ、コマンドを提供します。いずれ、Solaris OSの他の部分もこのプロジェクトを通じて、使えるようになるでしょう。

 OpenSolarisプロジェクトとSolarisオペレーティングシステムの違い。

 OpenSolarisプロジェクトは、エンドユーザー製品や完成品のディストリビューションを提供しません。OpenSolarisプロジェクトが提供するのは、オープンなソースコードのベース、コードの開発に必要なビルドツール、そしてコミュニケーションと関連情報の共有に必要なインフラストラクチャーです。コードのサポートは、コミュニティーが提供します。Sunは、ソースの形態でも、バイナリの形態でも、OpenSolaris製品には一切サポートを提供しません。

 Solaris OSは、Sunが管理、サポート、販売するSunブランドの製品です。将来リリースされるSolarisオペレーティングシステムは、OpenSolarisのソースコードでビルドされることになりますが、サポートはSolaris OSの現行バージョンと同じです。OpenSolarisプロジェクトにはあっても、Solaris OSにはないソフトウェア、Solaris OSにはあっても、OpenSolarisプロジェクトにないソフトウェアがあります。しかし、適宜リリースしなければなりません。OpenSolarisプロジェクトは、OpenSolarisコミュニティーの開発作業のために、できるかぎり多くのソースコードをリリースすることを目的にしています。

設計原則

 OpenSolarisのベース、ソースコードは、ある設計原則と基本的価値観に基づき、長い時間をかけて開発されてきたものです。この原則と価値観を誠実に守ってきたのは、アプリケーションを開発したり動作させたりするのに、首尾一貫していて分かりやすい、安定した多機能プラットフォームをユーザーに提供するためです。このようなプラットフォームの特性とそれを実現している技術は、この設計原則の賜です。

 ソフトウェアは本質的に、時とともに進化し、常に改良が可能なものです。しかし、OpenSolarisには、この原則が具体化されておらず、あるべき姿になっていない部分があります。この原則はOpenSolarisの特徴としてはずせないものであり、貢献者は、どんなに小さな変更を行う時にも、これを念頭に置いて作業することが求められます。

 もちろんこの原則は、OpenSolaris特有のものではありません。これは最高品質のソフトウェアを作る設計の土台です。ソフトウェアは、オペレーティングシステムとそのオペレーティングシステムに対するユーザーの期待にフィットしてはじめて、使えるといえるのです。たとえば、新しい機能が非常にすばやく実装されたとします。しかし、保守については何も考えていなかった。これではそのソフトウェアは進化できません。ついには壊れてしまいます。もう1つ別の例をあげましょう。それ自体はいままでにない画期的な新機能だが、コードが分かり難く、デバッグも難しいソフトウェアの例です。このようなソフトウェアの保守は大きな負担になります。そのコードを書いた人だけでなく、その他すべての貢献者の負担になります。また、そのソフトウェアについて問い合わせをしてくるユーザーの負担にもなるのです。

 信頼性 (Reliability)

 オペレーティングシステムで何よりも大切なのが信頼性です。それは、シングルプロセッサのノートパソコンでも、メインフレームクラスのマルチプロセッサのシステムでも同じです。つまり、OpenSolarisは、データを損失、破損させることなく、正確な結果を出し、正しく機能しなければならないということです。また、何らかの障害が発生して正しく機能しなくなった場合に、その障害が最初に発生したときの、根本的な原因を突き止めることができるインフラストラクチャーがなければなりません。これで、ソフトウェアに起こった問題を解決できますし、また最初の障害が原因となって他の障害を引き起こすこともありません。

 可用性 (Availability)

 OpenSolaris は、その信頼性を損うことなく、最大限の可用性を 実現するシステムでなければなりません。オペレーティングシステムは、ソフトウェアの障害に対しても、そしてできれば、ハードウェアの障害に対しても堅牢でなければならないということです。アプリケーションに障害が発生しても、サービスが再起動できるような設計にしておかなければなりません。またハードウェアの障害があっても、それが致命的でない場合は、OpenSolaris自体が復旧できるようにしておかなければなりません。新しいサービスをオンラインにしたり、サービスをオフラインにしたり、ソフトウェアやハードウェアのコンポーネントを修理したりするのに、いちいちOpenSolarisの再起動を求めるような設計をしてはいけません。

 保守容易性 (Serviceability)

 ソフトウェアのどのレベルにも問題が存在する可能性があります。さまざまなハードウェアレベルに問題が存在するかもしれません。だからこそ、オペレーティングシステムは、その問題を診断する機能を備えることが重要です。新しい機能は、できるなら、既存の監視メカニズムを利用して、実行中のシステムと実行後に得られるクラッシュダンプで、何が起こっているかを監視する方法を備えていなければなりません。OpenSolarisは、どこか他でその問題が再現されること、あるいは監視機能を備えた診断ソフトウェアを必要としてはいけません。そういうことを求めるのではなく、稼働環境で、未確定の問題を診断できるようにしなければならないのです。致命的な問題も一時的な問題も診断できなければならないし、できる限りその診断は自動化されていなければなりません。診断が自動化できない場合は、その診断方法を文書化して、他の誰にでも問題の性質がわかるようにしておかなければなりません。

 セキュリティー (Security)

 コンピューターの世界では、悪意のある行為が増えています。OpenSolarisでは、1つ1つのコンポーネントとサブシステムを厳しい目で検討し、 オペレーティングシステムそのものにセキュリティー機能を組み込まなければなりません。オペレーティングシステムは、システムに加えられた変更およびその変更を行った人を監査するメカニズムを備え、特別な設定をしなくても安全が保証されている必要があります。また、セキュリティーが破られた場合、その状態にさらされる時間をできるだけ短くする設計になっていなければなりません。

 パフォーマンス (Performance)

 オペレーティングシステムにとって、正しい答えを得ることはあたりまえのことですが、その答えをすばやく得ることも目標の1つです。つまり、OpenSolarisのパフォーマンスは、同じような環境で動いているどんなオペレーティングシステムにもひけをとらないくらい速くなければなりません。 オペレーティングシステムは、大きな負荷がかかってきたときに、パフォーマンスが落ちてはならないし、またシステムで利用可能なハードウェアリソースと釣合のとれたパフォーマンスを発揮しなければなりません。OpenSolaris は、リアルタイムアプリケーションをサポートするために、決定性待ち時間に対処できる必要があります。

 管理容易性 (Manageability)

 オペレーティングシステムと、その上で動作しているハードウェアはますます複雑になっているので、それを効率的に管理することに高い優先順位が与えられるようになってきました。OpenSolarisは、システム管理をさらに複雑にするのではなく、管理を簡素化する強力な抽象化機能を備えていなければなりません。また、一貫性のあるわかりやすい方法で、ソフトウェア・ハードウェアの区別なく、個々のコンポーネントを管理できなければなりません。

 互換性 (Compatibility)

 ソフトウェアスタックの各レベルで長期的に互換性を維持することは、単なる目標ではなく、1つの制約だと考えなければなりません。OpenSolaris のインタフェースは、ドキュメント化されたコミットレベルに沿って設計されなければなりません。また、このようなインターフェースに対する変更は、コミットした時点の互換性を維持するように設計されていなければなりません。新しいサブシステムとインターフェースは、拡張可能でバージョン管理ができるものでなければなりません。これは将来の機能強化や変更を互換性を犠牲にすることなく行えるようにするためです。インターフェースを削除する場合も含め、インターフェースの互換性に変更がある場合は、この変更のことがコミュニティーに知らされなければなりません。

 維持容易性 (Maintainability)

  ソフトウェアは、いくら時間が経っても変わることのない、静的なアルゴリズムの集合体ではありません。新しいニーズや要求の発見とともに、進化し続けるもの、それがソフトウェアです。OpenSolarisのフレームワークは、特に大規模な開発コミュニティーが長期的に保守しやすい設計になっていなければなりません。OpenSolarisは、任意の数の消費者が利用できるライブラリやカーネルモジュールに良く使うサブルーチンが組み込まれるように設計されなければなりません。ソースコードではコメントを効果的に使ったり、ソースコードの他に設計ドキュメントを書いたりして、OpenSolarisが良く分かるドキュメントを整備しなければなりません。

 プラットフォーム中立性 (Platform Neutrality)

  OpenSolarisは単一のソースベースからビルドします。また、その性能と機能は、ほとんど例外なく、すべてのプラットフォームで同じです。 OpenSolarisは常にどのプラットフォームからも中立でなければなりません。また下位レベルの抽象化機能は、複数のプラットフォームと未来のプラットフォームを念頭に置いて、設計されなければなりません。

プロセス原則

 OpenSolarisに貢献するためには、プロジェクトの設計原則を理解するだけでは不十分です。開発プロセスの中で設計原則を実践しながら、その厳守を促し、最終的には将来の開発作業で設計原則を100%実現できるようにすることが重要です。 プロジェクトに貢献する人はこの開発プロセスを理解しなければなりません。

 開発プロセスは、これまでの開発経験から引き出された数多くの価値に基づいて考え出されました。それは、さまざまな層とサブシステムにまたがる大きなプロジェクトから、極めて局所的な不具合を直す簡単で小さな修正にまでいたります。この価値の1つ1つ、プロセス原則の1つ1つが、新たにプロセスを考え出す際の道案内になります。OpenSolarisの継続的な進化が最大の目的です。常に最高品質を念頭に置いて、できる限り効率的に開発を進めるために考え出されたのが開発プロセスなのです。

 オープン性

 OpenSolarisを使い、学び、ついにはこれを変える権限をもった貢献者がたくさんいます。この方々がOpenSolarisのプラスになっているのは明らかです。したがって、OpenSolarisは、公の場で開発されなければなりません。その開発プロセスは、誰にでも見えるように、そして、すべてのレベルに参加できるようになっていなければなりません。

 必要のないステップはやらない

 OpenSolaris開発プロセスの各ステップはそれぞれ重要な役割を担っていますが、提案されている変更のタイプによっては、適用できないステップがあったり、ステップの適用範囲が広すぎたりすることがあります。プロセスは、コンソリデーションのリリースブランチの品質が危うくなったり低下したりしない範囲で、ステップの完了に必要な時間や物を可能な限り減らし、最適化し、必要でない場合はステップ自体をなくしてしまう、といったことのできる設計になっていなければなりません。

 公平性

 開発プロセスは、コミュニティの貢献者全員を公平に扱う運用ができる構造になっていなければなりません。プロセス内の個々のステップのどの範囲に着目するか、および、個々の貢献者に何を期待するかは、貢献者個人ではなく、その人が貢献している内容に基づいて決める必要があります。

 計画性

  OpenSolaris開発プロセスの各ステップで扱うのは、非常に限定されたものです。コンソリデーションにコード変更を貢献するために本当に必要なものに限られます。ですから、開発者は明確な意図をもってステップの開発をしなければなりません。計画性なく、勝手気ままなやり方で、ステップを追加したり、変更したりしてはいけません。これまでに得られた実際のデータや分析結果に基づく正当なやり方で、現行プロセスの問題点を1つ1つ明らかにし、その問題を解決する最善の方法を判断しなければなりません。

ポリシー

 OpenSolaris のコンソリデーションは、特定の例外が運営委員会もしくは運営委員会が指名する人によって承認され、その会議の議事録に文書化されるかファストトラック (簡易評価プロセス) 対象として認められたもの以外は、下記のポリシーに従わなければなりません。このポリシーは各技術分野について、多くの利害関係者の立場を配慮しながら、プロジェクトチームおよびコンソリデーションに対する要件を最小限にまとめたものになっています。貢献者の利益のために、コンソリデーションでは(個別でも全体でも)、このポリシーを繰り返して実践することが期待されています。

 サードパーティーのオープンソースソフトウェアなど外部コードベースについては、コンソリデーションでこのポリシーを緩める場合があります。たとえば、ONコンソリデーションでは、統合するオープンソースソフトウェアが国際化ポリシーを満たす必要はありません。

 アクセシビリティー

 すべてのOpenSolarisソフトウェアは、米国リハビリテーション法 508 条のアクセシビリティー規定に準拠します。

 アーキテクチャー評価委員会 (ARC)

 OpenSolarisに統合されるソフトウェアはすべて、OpenSolarisインターフェース分類法に従います。

 アーキテクチャーの中立性

 すべての汎用コード（つまり、ハードウェアに依存しないコード）は、OpenSolarisがサポートするすべてのターゲットプラットフォームでテストされ、実行されます。コードが持続的に機能することを確認し、そのためのリソースを確保してから、コードを統合します。

 機能削除 (EOF:End of Feature)

 次のような場合、OpenSolarisのマイナーリリースで、ユーザーの目に見える機能を削除できます。

 (1) 運営委員会（あるいは運営委員会が指名する人）と ARC が、実際の削除までの期間を明示する公告を承認した場合。
 (2) 運営委員会（あるいは運営委員会が指名する人）と ARC が実際の削除を承認した場合。
 ユーザーの目に見える機能のコミットレベルは通常、流動的かそれ以上です。特定のグループにしか見えない機能（たとえば、契約者のみ、パートナーのみ）は、ARC の承認があれば削除できます。削除までの期間はその特定グループが決めます。

 国際化 (I18N)/ローカライズ (L10N)

 すべてのOpenSolarisソフトウェアは、国際化されます。つまり、メッセージ、数値、日付のフォーマットやその他データの表現方法を、ユーザーのロケールに対応するものと置き換えることのできるインタフェースを呼び出します。ローカライズしたデータ表現を提供してもらうことは歓迎ですが、最初にコードを記述してコンソリデーションに貢献するときに、それらも用意しなければならない、ということはありません。

 IPv6

 IPv4をサポートしているOpenSolarisソフトウェアは、IPv6もサポートします。また、明確な目標を設定し、その実現に必要なリソースを集めて、妥当な時間内にIPv6サポートを実現するプランを立てます。

 コンソリデーションバグポリシー

 貢献者は、コード変更をコンソリデーションのリリースブランチを通じて公表する前に、新しい機能にあるすべてのバグを解決しておく必要があります。バグが解決されたかどうかは通常、コンソリデーションによって決まります。たとえば、あるコンソリデーションでは、優先順位の高いバグが修正されていないプロジェクトは統合してはいけない、と明示することもあります。運営委員会の代わりに、コンソリデーションを管理するチームによって例外が認められる場合もあります。このような例外は、コンソリデーションが先例を確立し、予測可能なものになるよう、文書化されることが期待されます。

 貢献物のライセンス

 貢献していただいたソフトウェアはすべて自由に改変ができ、また再配布が可能でなければなりません。共同開発および頒布ライセンス (CDDL:Common Development and Distribution License) あるいは、このCDDLと矛盾しないライセンスを使用します。

リリース管理

リリースタイプ

 OpenSolarisの中核的価値である互換性と、これを達成するために設計されたプロセスは非常に困難で、革新の妨げになっているように見えます。このセクションでは、そのプロセスの概要とプロセスの範囲内で何ができるかをおおまかに見ていきます。詳細を知りたい方のために、参考資料のありかも示していきます。

 まず、知っておかなければならないのが、Solaris10とSolaris 2.0の違いは大変に大きいということです。Solaris10とSolaris 2.0の間に行われたSolarisの革新はすべて、今と同じ互換性の制約内で達成されたものです。

 まさにこの互換性の制約は、革新の妨げではなく、促進剤なのです。これを「制約の自由」といっています。プロジェクトが依存しているインターフェースに制約があれば、プロジェクトの開発に集中できます。絶えず変化する環境に合わせる必要はありません。

 互換性を促進するように設計されたプロセスを理解し、そのプロセス内で仕事をするために知っておくべき基本的な考え方がいくつかあります。

 ソフトウェア業界では通常、リリースをメジャー、マイナー、マイクロに分類し、これを「ドット」記法で表現します。われわれは皆これを良く目にします。ソフトウェア業界におけるこのメジャー、マイナー、マイクロという呼び方は、リリースが小さい、中くらい、大きいと言っているのと大差ありません。マーケティング用の宣伝文句に過ぎないのです。

 しかし、SolarisならびにOpenSolarisでは、リリースタイプ（メジャーか、マイナーか、マイクロか）によって、互換性のあるインターフェースの変更にそれぞれ制約があります。メジャーリリースでは、互換性のないインターフェースの変更がありえます。マイナーリリースでは、互換性のないインターフェースの変更はほとんどありません。マイクロリリースでは、そういう変更の可能性はさらに低くなります。各インターフェースにはインターフェース分類法（リファレンス）によるレベルがあって、どのインターフェースがどれにあたるのかはそれでわかります。インターフェース分類法のレベルについては後で詳しく述べます。

 さきほど第2段落で、「Solaris 2.0」と「Solaris 10」に言及しました。「Solaris 10」は、「メジャーとマイナーをドットで区切る」Major.Minor記法を使えば、実は「Solaris 2.10」です。しかし、Sunが当面Solarisのメジャーリリースをしないことにしたため、メジャーを示す「2」を取ってしまいました。ただし、コマンドラインで、uname -r を実行すると、SunOS コンポーネント（コンソリデーション）のリリース番号がMajor.Minor[.Micro]という完全な形で出てきます。 リリース番号の頭から「2」を取ってしまったのは、互換性という中核的価値に取り組む積極的な姿勢を示すもので、OpenSolarisにも同じ姿勢が求められます。SolarisとOpenSolarisのマイナーリリースには、「大規模で魅力的な機能更新、しかも互換性あり」という意味があります。

 では、これから、インターフェースの安定性とインターフェース分類法の話をしたいと思います。インターフェース分類法は現在修正中のドキュメントです。この修正は分類法の単純化が目的ですが、オープンな環境で仕事をする人の要求に対応するためでもあります。このドキュメントはまだ最終的な完成版としてみなさんに利用していただくことはできませんが、実質的な変更ははっきりしていて、その概要は以下のとおりです。

 インターフェース分類法では、インターフェースを大きく2つのカテゴリに分けます。 公開（パブリック）と非公開（プライベード）です。公開インターフェースは、誰でも使えます。一方非公開インターフェースを使える人は、そのインターフェースを使う可能性のある人に限られます。公開インターフェースにも非公開インターフェースにも、複数のサブクラスがあります。公開インターフェースのサブクラスは、互換性のないインターフェースの変更をどのリリースタイプで行うかで分けられます。非公開インターフェースのサブクラスは、どんなユーザーをサポートするのかで分けられます。

 非公開というのは、決して、秘密という意味ではありません。逆に、目に見えるということが公開なのではありません。非公開インターフェースを見つけるのは簡単です。ヘッダーファイルを調べればすぐに見つかります。

 公開インターフェース分類の（新しい）レベルは次のとおりです。

安定 (Stable):安定インターフェースではメジャーリリースに際してのみ互換性を損なう変更が許されます。独立系ソフトウェアメーカー (ISV) やシステムインテグレータ (SI) 向けのインターフェースは、このレベルのサポートが求められます。ISV顧客、SI顧客にはどうしても必要なサポートです。

不確実 (Uncommitted):不確実インターフェースではメジャーまたはマイナーリリースでのみ互換性を損なう変更が許されます。これは、一部システム管理施設およびまだテストをしていない新しいインターフェースに適切なレベルです。
流動的 (Volatile):流動的インターフェースではどんなリリースタイプでも互換性を損なう変更が許されます。このレベルが有効なのは、通常、OpenSolarisコミュニティ以外の企業や団体がインターフェースの仕様を決めていて、コミュニティの要望に応えるのがインターフェースの互換性よりも大事だと思われる場合だけです。
インターフェースでない: サポートされているように見えるが、実はサポートされていないインターフェースに付けた便宜的な名前です。インターフェースの分類では、これがデフォルトになります。サポートされているかどうかよく分からない場合にのみ、これを明示的に適用します。

公開インターフェース分類レベルの呼び方は、インターフェース分類法ドキュメント更新の際に改めるかどうか議論中です。

 あるリリースタイプで互換性のない変更を行う能力があるかどうかは、必要条件ではありません。たとえば、OpenSolarisコミュニティ以外の人が管理するインターフェースのほとんどは、現在「流動的」に分類されます。しかし、コミュニティが互換性のない大きな変更を導入した場合、その変更の同期はマイナーリリースが出るまでしばしば延期されます。

 このルールには例外がありますが、よほどの理由がないかぎり例外は認められません。受け入れ可能な理由は次の3つです。

1. サポートされているスタンダード（つまりブランド）の解釈が変わって、既存の実装コードがそれに合わなくなってしまった場合。
2. インターフェースの仕様そのものにセキュリティホールがあった場合。
3. インターフェースの仕様そのものにデータの破損があった場合。

 この他の理由については、ケースバイケースで受け入れられることもあります。たとえば、Microsoftが8.3 DOSのサポートを止めてしまったとき、われわれは pcfs (小文字でpcfsです) の互換性維持をやめました。われわれがそうしなかったら、世界中の人々はわれわれを愚か者だと思ったでしょう。

 OpenSolaris (特にコアのON/SunOS コンソリデーション) は、ほとんど「不確実」分類レベルを使いません。このレベルを使うのは、主に、互換性の低い制約されたマーケットで使われる他のSun製品です。しかし、次の2つの理由で、このレベルを使う人の増加が予想されます。

• その「他のSun製品」がOpenSolarisの一部になる見込みだからです。(これは、コアのON/SunOSコンソリデーションには影響ありません。)
• 現在「流動的」に分類されているインターフェースは、「不確実」にレベルアップされているところです。これらのインターフェースを使う人が増えているので、マイクロリリースの互換性は、今や速いペースで外部コミュニティの要望をフォローする切札になっています。(これは、ON/SunOSコンソリデーションに影響があります。)

 非公開インターフェースの分類レベルは以下のとおりです。

プロジェクト限定公開: そのインターフェースを提供するプロジェクトにのみ使われるものです。これが非公開インターフェースのデフォルトです。公式レビューを必要としません。しかし、後の可用性を考えると、レビューは有効です。(OpenSolarisは、「プロジェクト」と「コミュニティ」とほぼ同等のものと見なしています。)

コンソリデーション限定公開: そのインターフェースを提供するプロジェクトを含むコンソリデーション内でのみ使われます。
OpenSolaris限定公開: (Sun内部ということで、Sun限定公開といわれているものです。) OpenSolarisのコンポーネントであれば、どのコンポーネントにでも使えます。しかし、これはあまり良い選択とはいえません。もし、互換性のない変更が出てきた場合、コーディネートする仕事が必要になってくるからです。

 これはOpenSolaris開発者にどんな影響を与えるでしょうか。

 自分の使える（あるいは使うことを許されている）インタフェースがはっきり分かり、これに基づいて適切な判断ができます。これが大きなプラス面です。他のプロジェクトがあなたのプロジェクトに与えるインパクトを最小限に抑えることができます。このメリットが分かるのは先のことになります。短期的には不都合に思われるかもしれませんが、長期的には大きなメリットをもたらします。

 マイナス面は、互換性を維持するためにあなたのプロジェクトが提供するインターフェースを修正する必要が出てきた場合、くぐり抜けなければならない輪がいくつかあるということです。昔からあるUNIXの例が、wait/wait3/wait4/waitpid/...というルーチンのセットで、このルーチンが必要とするセマンティクスが進化すると、古いルーチンは進化をやめ、要件を満たさなくなります。すると新しいルーチンが発明されますが、古いルーチンは依然として使えますし、互換性もあり、サポートもされます。このような極端な例は稀れでしょう。よく見られる一般的な結果は、完全な白紙から始めるより「多少」エレガントさには欠ける方法でインターフェースを進化させる必要が出てくるということです。この「多少」という言葉がミソです。

ブランチ管理

 OpenSolarisの運営ポリシーは、同時並行で複数の開発ラインが存在することを前提にしています。1つの開発ラインは、コードベースの一部に関連していますが、いつもコンソリデーションであるというわけではありません。さまざまなコンソリデーションが開発ラインに関係していますが、同時にリリースを完了する必要はありません。既存のSolaris開発モデルだけでなく、多くのオープンソース開発プロジェクトがこれを前提にしています。

 並行開発の説明に使う用語は、使用している特定のソースコード管理モデルに依ります。しかし、基本的な仕事の流れはほぼ同じです。混乱を避けるため、用語の定義については用語集をご覧ください。

 コンソリデーションがその最新リリースを最終版とする、つまり、そのリリースの公式スナップショットが出る前に、トランクは2つのリリースブランチに分けられます。1つはトランクで、これに次のリリース向けの開発成果が統合されます。もう1つが最新リリースブランチで、ここで最新リリースを完成し、最終版とします。リリースブランチを分けたとき、トランクでは次のリリースに合わせてソースベースにあるバージョン情報を変えます。前のリリースブランチのバージョン情報はそのままにしておきます。リリースチームは、バージョン付けされたリリースに対応しています。このステップは、新しいリリースチームによる新しいトランクの作成に見えるかもしれません。既存のリリースチームは、担当する前のリリースブランチが最終版になるまで、そのブランチに責任を持ちます。

 すべてのリリースブランチは、後にこの文書で説明する品質基準に従います。とはいえ、リリースチームは、アトランダムに選ばれた任意のスナップショットを神聖視しません。これらスナップショットはディストリビューションで使われる可能性があるので、最終版スナップショットだけをコンソリデーションのコンテンツの公式リリースと考えます。人間は間違うものですから、不完全なリリースブランチには、公式リリースにあってはならない欠陥が含まれてしまうことがあります。ですから、リリースを最終版にするときには、変更の回数を減らして、そのような欠陥を締め出す必要があります。

 リリースチームは、どのブランチでも、リスクを最小限に抑えるため、プロジェクトがブランチに統合できる状態になっている同時に、ブランチがそのプロジェクトを受け入れる状態になっているときにだけ、プロジェクトの統合を求める責任と権限を持ちます。つまり、統合時期が遅い段階に設定されているプロジェクトは、次のリリースがオープンされるまで統合が延期されることがあります。

 では開発サイクルをいつ「分ける」のか。それはバランスの問題です。新しいリリースの初期段階付近で「分ける」と、2つのリリースブランチで同時に開発作業を行っている時間が長くなってしまいます。リソースが分散し、マージの回数も増えます。リリースの完了段階付近で「分ける」と、前のリリースが完了するまで、次のリリースがオープンされないことになってしまいます。これでは、プロジェクトの統合が大幅に遅れます。

アクティブなブランチとそれに相当するリリース。

 OpenSolarisを正式に構成するコンソリデーションのトランクは、通常、常にマイナーリリースのバインディングルールのもとで運用され、各リリースチームのコントロール下にあります。

 ブランチの分割後、延期されているリリースブランチは、そのリリースが完了するまで、マイナーリリースのバインディングルールに従いますが、統合のスピードは遅くなります。新たな開発のターゲットは次のリリースにすべきです。延期されているリリースを担当するリリースチームが、リスク管理を理由として、統合を拒否するかもしれないからです。

 ブランチの作り方としては、最終リリースから作成し、継続的な開発に開放するという方法もあります。この場合、そのブランチは、アップデートリリースになります。各アップデートリリースには、担当のリリースチームがあり、マイクロリリースのバインディングルールに従います。各アップデートリリースチームは独自の統合基準を設定することができますが、通常、アップデートリリースをターゲットにしている変更はすべて、まずトランクに統合されます。そして、マージはしないで、アップデートリリースブランチにバックポートしなければなりません。また各ステップで行うテストはそれぞれ独立したものにする必要があります。ほとんどのアップデートリリースチームは、ある程度トランクでの「検証期間 (soak time)」が必要になるでしょう。「検証期間」の長さは、変更のタイプと範囲に依ります。リリースチームには常に、そのチームが適切だと判断する要件を追加する権限があります。

 トランクに変更を統合する際に生成されるものはほとんど、アップデートに統合するプロセスで再利用されるのが普通です。アップデートの統合プロセスで一番大切なのは、その変更がアップデートリリースに適切かどうかということです。

リリースバインディング

 リリースチームは、担当ブランチへの変更に適切なリリースバインディングを定義します。これは通常、アップデートリリースブランチではマイクロで、その他のリリースブランチではマイナーです。プロジェクトのブランチは通常、それをターゲットにしているリリースブランチと同じリリースバインディングルールに従います。統合をターゲットにしていないプロジェクトチームは、担当するブランチで使いたいリリースバインディングルールがあれば、どんなルールでも適用できます。

 リリースの定義からわかるように、1つのリリース内で互換性のルールを適用することはできません。ルールを設定できるのは完成した子リリースと完成した親リリースの互換性だけです。このルールは、あるリリースのスナップショットから次のスナップショットに適用することはできません。しかし、不具合のなかには互換性のない変更で修正するのが最も簡単だという場合があります。ここは特に注意が必要です。新しいインターフェースがリリースブランチに統合され、このようなタイプの不具合が発見される前に、別のリリースブランチにバックポートされることがあります。どちらかのブランチが完了する前に、両方のブランチに対して同じ互換性のない変更を行う場合は、しっかりとしたコーディネーション、調整作業が必要になるでしょう。

品質基準

 OpenSolarisは、いくつものオープンソースプロジェクトを取り込んでいきます。これらプロジェクトはOpenSolarisのガバナンスモデルに従います。各プロジェクトは、それぞれ品質保証や不具合管理を含む運用方法のルールをある程度自由に決めることができます。しかし、OpenSolaris内のプロジェクトが、トランクを含むコンソリデーションのリリースブランチを通じて、その変更を公開したい場合、その提案されている変更は一定の品質基準を満たさなければなりません。

リグレッション（機能後退）コミット基準

 リグレッション（機能後退）とは、正しい動作と違う、意図していない動作のことです。正しい動作というのは、文書化されている動作、あるいは期待される動作のことです。リグレッションの1つのタイプは、文書化された規定の仕様に従わないオペレーティングシステムの動作です。このようなリグレッションのなかには、これまでに見たことのないエラーメッセージが出るといった些細なものもあれば、オペレーティングシステムが突発故障を被るといった深刻なものもあります。機能後退の原因となるような変更があってはなりません。リリースブランチに対する変更が、そのブランチの現在の状態からの機能後退の原因になってはならないということです。このようなリグレッションがあると、OpenSolarisをベースにしたすべてのプロジェクトが、リグレッションの影響が考えられる問題を突き止めるのに時間をとられることになります。これは時間の浪費です。そのリグレッションを導入してしまった貢献者だけでなく、コミュニティ全体の問題になります。また、将来に向けて開発作業のスピードを遅くすることにもなります。提案された変更をコミットする前に、厳密かつ総合的なテストプランを実行することによって、ほとんどの場合、機能後退を防ぐことができます。

 リグレッションのもう1つのタイプは、1つ以上のマイクロおよび/またはマクロベンチマークからのシステムパフォーマンスの後退です。このようなリグレッションは、できる限り回避しなければなりません。機能後退を防ぐのに使ったのと同じテストを行えば、システムパフォーマンスの後退も防ぐことができます。各リリースブランチには、そのリリースが達成すべきパフォーマンス基準（この基準はリリースの品質基準の一部になります）が設定されるので、それに従いリリースチームは、提案された変更によるパフォーマンスの後退を許すことがあります。それを許すか許さないかは、そのブランチの基準と、リリースが現在その基準を達成しているかどうかに依ります。

完全コミット基準backmatter

 リリースブランチに新しく導入した変更がリグレッションを引き起こさない場合でも、その変更が予想通りの動作を引き起こすかどうか確認することは大切です。新しい機能は、プロジェクトチームが設定した主要な要件を満たさなければなりません。これは、厳密なテストプランを行うことによって確認できます。このテストプランは検証の結果、総合的かつ完全なプランと認められたものです。主要な要件を満たしていることを示せないプロジェクトには、コンソリデーションのリリースブランチを通じて、その変更を公開することが許可されません。

 また、どんなタイプの変更であれ、リリースブランチに変更があった場合は、それをテストするリグレッションテストスイートにも対応する変更を行う必要があります。特に新しい機能を追加した場合にこれが当てはまります。そのリリースブランチに最初の変更を行ったプロジェクト以外のプロジェクトが、その後、同じリリースブランチに対して変更を行うというのはよくあることです。リリースブランチに変更があった場合にリグレッションテストスイートにも対応backmatterする変更を行っておけば、その変更がOpenSolarisの品質を後退させるものでないことを示すことができます。既存の不具合を修正した場合も、それまで使ってきたテストスイートに他のテストスイートや条件を追加すれば、役に立つことが多く、またそうすることが必要になってくることもあります。大切なのは、堅牢なテストスイートです。すべてのOpenSolaris貢献者が使えるテストスイートです。このようなテストスイートがあってはじめて、提案された変更が機能的に完全で、機能後退を引き起こさないものであることを、可能な限り最大限保証できます。

品質のまとめ

 「常に生産現場に出せる状態」というのが、おそらくOpenSolarisの品質要件を最も良く言い表す言葉でしょう。コンソリデーションのリリースブランチは常に必要十分な品質を備え、そのまま、世に出すディストリビューションや製品のベースとして使えるものでなければならないという考えです。コミュニティは、厳密な品質基準を守ることによって、 できるかぎりOpenSolarisが品質のデススパイラル、つまり悪循環に陥らないようにすることができます。このデススパイラルの始まりは、貢献者やユーザーが同様に、ブランチが壊れているという話を聞いたときです。彼らは、最新の変更を自分たちのプロジェクトの領域に入れないようにします。ブランチそのものを使わない人も出てきます。こうなると、実環境テストをする人が少なくなります。バグが発見されなくなり、ブランチの品質がさらに低下します。デススパイラルが始まってしまうと、それを食い止めるのは難しく、復旧にはとても長い時間がかかります。

 backmatter

開発プロセス

  開発プロセスの流れを1つのフローチャートで示すのは難しいので、その流れを、発想、設計、実装、統合の4つに分けます。先に述べましたが、OpenSolaris開発プロセス基準の1つに「必要のないステップはやらない」があります。これは、プロセスのさまざまなステップは、必要な場合に限って適用し、必要のない場合はやらないということです。開発者は、「ステップを全部やらない」こともできますし、順番どおりにステップを踏まなくてもかまいません。しかし、やり直しのリスクが高くなります。何よりも大切なのは、何が必要で、何が必要でないかを的確に判断する力です。

 図の色は、適用範囲を示しています。

• 薄い灰色のボックスはすべての変更に適用。
• 青いボックスは中規模および大規模な変更に適用。
• 明るい青のボックスは大規模な変更にのみ適用。

発想

 まず、誰かが改善のアイデアを思い付いたり、不具合に不満を感じたりします。最初にやるべきことは、バグやRFEがファイルされているかどうかを確認し、ファイルされていなければ、それをファイルすることです。次に、それをどこか適当な場所に発表し、ディスカッションに参加します。そうすれば、提案しようとしている変更の複雑さがどれほどのものか判断できます。その変更に対するコミュニティの関心度を測り、その変更に取り組んでくれるチームメンバーを見つけることができます。このようにして、開発者は、先に進むのに必要なサポートを得られるかどうかがわかります。変更の規模が大きい場合は、それに取り組むチームを編成する必要があります。その変更に取り組むプロジェクトを立ち上げる必要があるかもしれません。変更の設計を評価してくれる人が必要になるかもしれません。このような要件がすべて満たされたら、具体的な設計の段階に進むことができます。

設計

 設計の段階では、複数のことが同時に並行して進みます。まず、公式な設計の評価が必要なのかどうかです。一般に、小規模なRFEとバグフィクスには必要ありません。中規模および大規模なRFEとプロジェクトには必要です。しかし、多くのプロセスと同様、これはそのときどきの判断に依ります。公式な評価が必要な場合は、評価者を見つけてこなければなりませんし、評価対象となる設計がなければなりません。アーキテクチャの評価が必要になってくる場合もあります。他のプロジェクトなどに依存性がある場合には、その設計が適切であることを利害関係者に説明し、納得してもらわなければなりません。それが最小限のものでも、複雑なものでも、テストプランを作成し、これにも賛成してもらわなければなりません。さらに、リソースを明らかにして、スケジュールを立てる必要もあります。

実装

 実装の段階でも、複数のことが同時並行的に進みます。このなかでまず、真っ先にやらなければならないのが、実際にコードを書くことです。コードが適用可能なポリシーに従っていること、さまざまなユニットテストや統合前テストに合格していることを確認しながら、コードを書き進めます。同時に、ドキュメントを書き、テストスイートを書きます。また統合の段階に進む前に、コードの評価者をはっきりさせておきます。

統合

 統合の段階は、やるべきことがすべて、実際にやられているかどうかを確認する段階です。つまり、コード、ドキュメント、その完全性など、たくさんのことを評価する段階です。「完全性の評価」というステップを行うのは、最終評価者です。Solarisのモデルでは、C-チームおよび/またはCRTがこれに当たりますが、はっきりと最終評価者に指定されているわけではありません。しかし、担当するコンソリデーションについては、最終評価者と同等の役割を果たすものと考えられています。評価がすべて完了し、統合の許可が出たら、統合が行われます。そして、このような変更があったということを各所に伝えなければなりません。必要に応じて、注意(heads-up)および/またはフラグデイのメッセージを関連コミュニティに送ります。また、サポート組織にそれを伝えなければならない場合もあります。

用語集

 アプリケーションバイナリインターフェース (ABI)

 開発は、各ブランチから個別に進められますが、ブランチの統合ルールに 従って、どちらかの方向にブランチ同士のマージが発生することもあります。

 ABIは、コンパイル済みプログラムのシステムインターフェースを定義します。ABI は通常、ソースをバイナリに変換するルールと API の総称として 使用されます。

 アプリケーションプログラミングインターフェース (API)

 開発は、各ブランチから個別に進められますが、ブランチの統合ルールに 従って、どちらかの方向にブランチ同士のマージが発生することもあります。

 APIは、ソースレベルでプログラムのシステムインターフェースを定義します。

 ブランチ

 コードベース内の開発ライン。別のブランチ、通常はトランクのスナップショットから作成されます。開発は、各ブランチから個別に進められますが、ブランチの統合ルールに 従って、どちらかの方向にブランチどうしのマージが発生することもあります。ブランチのタイプは一般に2つあって、それは、リリースブランチとプロジェクトブランチです。

 Cチーム

 コンソリデーション (Consolidation) チームのこと。ある特定のコンソリデーションを管理するリリースチーム。

 変更評価チーム (CRT)

 変更評価チームは、技術貢献者のグループです。ある特定のCチームは、提案されている変更の技術的なリスクとメリットを評価するという日常的な作業を管理するためにCRTを編成することがあります。CRTが評価するのは、ある程度まとまった数のバグに対するフィクスを統合したいというリクエストです。プロジェクトの統合リクエストはコンソリデーションのリリースチームが管理します。

 コマンドラインインターフェース (CLI)

 CLIは、コマンドラインツールの起動構文を定義します。

 コミュニティー

 コミュニティーは、1つまたは1つ以上の関心事を共有し、話し合いを行っている人（「メンバー」）のグループです。その話し合いは、1つまたは1つ以上の公開フォーラムで行われます。コミュニティーがソースリポジトリを持つことは期待されていません。コミュニティーに期待されているのは、そのコミュニティーが関心を持っている分野に関連した1つまたは1つ以上の進行中のプロジェクト、あるいは、そのようなプロジェクトを出すコンソリデーションに関心を持ちつづけることです。

 コンソリデーション

 コンソリデーションとは、オープンなやり方で1人または複数の人が作業している技術的な仕事で、1つまたは1つ以上のプロジェクトから生み出される技術的な成果物を組み立て、ディストリビューションの組み立てに都合の良い首尾一貫したまとまりにすることです。コンソリデーションは自分と同じ世代や他のソースからの貢献物を含む場合もあります。コンソリデーションには、1つまたは1つ以上のソースリポジトリがあります。このリポジトリは、貢献しているプロジェクトとその他成果物から選んだもののソースをまとめたものです。コンソリデーションの主要目的は、ディストリビューションに役立つ成果物を公開するメカニズムになることです。ユーザーの役に立つかどうかは、2次的な問題になります。コンソリデーションを構成するもの、たとえばプロジェクトは、通常貢献者によって構成されます。

 コンソリデーションの成果物として最低限期待されるのは、ソースツリー関連ツール、およびソースツリーをコンパイルして得られたファイルシステムに対するバイナリ配布である「プロト領域」です。backmatter ディストリビューションがどの程度コンソリデーションを利用するかに依りますが、そのバイナリをパッケージの形で公開する場合もあります。

 貢献者（人）

 貢献者とは、プロジェクトまたはコンソリデーションに役立つ仕事ができる人のことです。貢献者が行う仕事には、コードの作成または変更、障害の分析、プロジェクトに関係するツールの管理、アーキテクチャあるいは仕様を書いたドキュメントの作成などがあります。また、他の貢献者の行動をコーディネートすることもあります。ある仕事が貢献になるかどうかという判断は、プロジェクトかコンソリデーションに委ねられます。コミュニケーションに携わるプロジェクト、たとえば貢献者の権利擁護プロジェクトは、カンファレンスその他の物理的ミーティングへの参加といった個人の活動を貢献と考える場合があります。

 「コア（中核的）貢献者」という名前は、プロジェクトやコンソリデーションに実質的な方向性を与える貢献者に使われます。コア貢献者は、すべての投票および紛争解決メカニズムへの参加が期待されます。

 ディストリビューション

 ディストリビューションとは、オープンなやり方あるいはクローズなやり方で1人あるいは複数の人が作業している技術的な仕事で、1つまたは1つ以上のコンソリデーション、あるいはオプションで1つまたは1つ以上のプロジェクトから生み出される技術的な成果物を組み立て、所与のクラスのアプリケーションで通常使われる機能セットの意味あるサブセットを実行できるようなまとまりにすることです。ディストリビューションの主要目的は、ユーザーのことを考えた成果物の公開メカニズムになることです。ディスリビューションを構成するものは、通常貢献者によって構成されます。ただし、オープンでないプロセスを使うディストリビューションに、実際の貢献者が参加している必要はありません。

 ソフトウェアを生成するディストリビューションの成果物は、最低限、実行可能な形態になっていることが期待されます。

 ドキュメント

 人間が使用することを考慮したインターフェースの構文や意味を記述すること。これには、マニュアルページ、infoファイル、「ガイド」、READMEファイルなどがあります。ヘッダーやソースファイルのコンテンツはこれに含まれません。

 ファストトラック

 コミュニティの提案を評価する簡易プロセス。この簡易評価プロセスに合った提案は、明白なもの、議論の余地のないものです。ファストトラックによる評価は、通常一定の期間に電子メールで行われます。提案に割り当てられた時間内に、検討の価値がある重大な異議が出てこない場合は、自動的に承認されます。

 フラグデイ

 フラグデイは、コンソリデーションの開発リリース（あるいは最新バージョン）を使っている貢献者の多数に影響するコード統合の日です。たとえば、ビルドツールの変更で、ビルドのソースツリーから既存のオブジェクトファイルを削除する必要がある場合、これは通常フラグデイと考えられます。フラグデイは、統合を行う貢献者、あるいはその貢献者を代表するCチームの説明メッセージを伴います。このメッセージは、変更の詳細と、フラグデイ前後に必要となる継続的作業のステップを説明します。

 インターフェース

 メリアムウェブスター辞典は、インターフェースを次のように定義しています。

 2 a : それぞれ独立した、多くは互いに無関係なシステムが出会い、作用しあい、通信する場所。   b : インターフェースにおける相互作用や通信を実現する手段。
 この文書では、1つのソフトウェアオブジェクトがエクスポートする、あるいは別のソフトウェアオブジェクトからインポートする構文やセマンティクスを文書化したものに限ってインターフェースといっています。これには次のようなものが含まれます（ただし、これだけではありません）。

• ライブラリのABI（APIのこと）。
• ユーティリティのCLI。
• ファイルフォーマット。
• ファイルシステムのレイアウト（ファイルの場所を含む）。
   インターフェースを実装する際は、それを動作させたときの結果も考慮しなければなりません。それはある条件におけるパフォーマンスです。これは指定できるものではないので、「インターフェース」の一部にはなりません。実装する開発者は、このような文書化されていない機能に依存している人がいることを想定していません。クライアントはこのようなパフォーマンスに依存してはいけません（あるいは仕様の一部として明示しなければなりません）。しかし、インターフェースの機能や全体的なパフォーマンス特性は、インターフェースセマンティクスの一部と考えられます。

 インターフェース分類法

 インターフェースのコミットレベルに使われる用語を定義するドキュメントです。セマンティックな定義とリリースタイプのコミットレベルで使うルールも書いてあります。このコミットレベルは、「インターフェースの安定性」タイプのマニュアルの属性セクションに書かれ、顧客に公開されます。

 メンバー（人）

 メンバーは、自分がメンバーになっているコミュニティの話し合いに参加します。発言しないオブザーバーもメンバーです。

 親/子ブランチ

 新しいブランチが作成されたとき、それまでのコンテンツのソースとなっていた前のブランチを親ブランチといい、新しく作成されたブランチを子ブランチといいます。ブランチが作成されるとすぐに、親ブランチと子ブランチのコンテンツは同じになります。

 製品

 製品は、ディストリビューションの公開版です。少なくとも公開時には、製品だということがはっきりわかります。

 プロジェクト

 プロジェクトは、オープンなやり方で作業をしている1人または1人以上の人が関わっている技術的な仕事で、コーディネートされた少数の技術的成果物を作り出します。プロジェクトには1つまたは1つ以上のソースリポジトリがあります。それぞれ何らかの方法で公開することを目的に作られています。プロジェクトは、1つあるいは1つ以上のコンソリデーションによるものを、公開の第一形態にすることを選択できますが、必ずそうしなければならないということではありません。プロジェクトは少なくとも、活発にプロジェクトの作業をしている人（貢献者）と単にプロジェクトの進行に興味があるだけの人（メンバー）を区別しておく必要があります。

 プロジェクトブランチ

 プロジェクトチームが自分のプロジェクトの仕事をコーディネートするために使う開発ラインです。プロジェクトブランチは通常、コンソリデーションのトランクから作成されます。定期的に親ブランチをマージし、親ブランチにマージされます。プロジェクトが完了すると、このブランチは役割を終えます。コンソリデーションで公開するつもりのないプロジェクトは、既存のコンソリデーションのブランチとは異なるコードベースを使うことができます。プロジェクトはまた、複数のコードベースのそれぞれで、1つのブランチを持つことができます。

 プロジェクトチーム

 プロジェクトに貢献する人全員です。プロジェクトチームは、内部統制と開発プロセスの確立に責任を持ちます。また自分のプロジェクトブランチやコードベースに適切な変更とは何かという判断についても責任があります。

 プロト領域

 所与のソースツリーをコンパイルしたものを使ったバイナリ配布を内容とする階層ファイルシステムのこと。たとえば、/path/foo をルートとするソースツリーは、/path/foo/proto というプロトディレクトリを持つことができます。/path/foo/proto の下にあるものはすべて、プロト領域であるということができます。もし、/usr/bin/x と /etc/x.conf の両方がバイナリ配布の一部ならば、それらは、それぞれプロト領域の/path/foo/proto/usr/bin/x と /path/foo/proto/etc/x.conf にあります。

 リリースブランチ

 プロジェクトおよび/またはバグフィクスが統合された、公開を目的とするコンソリデーションのコードベースのブランチ。コンソリデーションは、いつでも複数のアクティブなリリースブランチを持つことができます。各ブランチにはそれぞれ担当のリリースチームがあり、統合要件もそれぞれ違います。

 リリース

 1つのリリースブランチのスナップショットあるいは一連のスナップショット群。リリースにはアーキテクチャの一貫性という要件が適用されます。

 安定

 OpenSolarisで最も一般的なインターフェースのコミットレベルです（インターフェース分類法をご覧ください）。安定インターフェースとの互換性を損なう変更は、製品のメジャーリリースでのみ行われます。

 この「安定」の使い方は、コミュニティで良く使われる、開発ツリーの安定ブランチでいう「安定」の使い方とは同じではありません。
 インターフェースの安定性レベルの情報はすべて、Solarisのマニュアルページ属性(5)にあります。

 トランク

 コンソリデーションの最新リリースブランチです。トランクは、一番最近開かれたリリースブランチで、そのコンソリデーションにバージョニングが採用されている場合、最大のバージョン番号が与えられます。他のブランチがリリースされる場合は、その前に必ず、すべてのプロジェクトと適用可能なバグフィクスがトランクに統合されます。ソースコードの管理システムで使うトランクという名前、およびこの名前が固定されるか、変更されるかは、実装時の固有事項です。トランクはトランクというブランチと他のブランチを区別する表現です。

 ユーザー（人）

 何らかの形で出力された、1つまたは1つ以上のディストリビューション、コンソリデーション、プロジェクトを使ってはいるが、それらを開発する作業に関連した話し合いに参加していない人のことです。ユーザーは、技術的な仕事のあつまりによって作り出される技術の純粋な消費者と見ることができます。

付録A インターフェースの分類法

 (PSARC/2005/220 がここに入ります。)