openSUSE:Factory 開発モデル
開発モデル
Factory は Open Build Service リファレンスサーバ上に構成された、 openSUSE:Factory というプロジェクト内で構築されています。リンク先をご覧になると分かりますが、ここには非常に多くのパッケージが用意されています。しかしながら、パッケージの開発それ自身は openSUSE:Factory 内で行なわれることはなく、それぞれの 開発 (devel) プロジェクト と呼ばれるプロジェクト内で行なわれます。 開発 (devel) プロジェクト とは、その名前のとおり、特定の分野のパッケージに対して開発作業を行なうためのものです。 開発 (devel) プロジェクト にはたとえば、 multimedia (マルチメディア), GNOME, KDE, Kernel (カーネル) などがあります。 openSUSE:Factory プロジェクト内のパッケージと対応する 開発 (devel) プロジェクト との間は、メタデータで関係性が設定されています。
開発 (Devel) プロジェクト
それぞれの 開発 (devel) プロジェクト には、それぞれのプロジェクトに最もあった方式で処理やルール、連絡手段などが用意されています。これらの情報を参照するには、 Build Service 内のプロジェクト内に書かれているプロジェクトの説明をお読みになると良いでしょう。 FOSS (フリーソフトウエア／オープンソースソフトウエア) の世界は常に進化し続けていることから、 開発 (devel) プロジェクト も常に変化に晒されています。ソフトウエアによっては古くなってしまうものもありますし、標準や既定値が変更される場合もあります。これにより、 開発 (devel) プロジェクト も名前が変更される場合があるほか、削除されたり新しく作成されたり、内容や方向性が変わったりする場合があります。もちろん 開発 (devel) プロジェクト 内のパッケージについても同様です。 開発 (devel) プロジェクト から Factory への提供状況を見るには、 このページ 内の上部にあるドロップダウンメニューをお使いください。また、 Factory への送信プロセス に関する概要説明をお読みになることもできます。
関連する詳しい情報については、 こちら をお読みください。
ステージングプロジェクト
特定の中枢パッケージ (たとえば GCC など) のバージョンが変わった場合、潜在的には全体の動作に支障がありうるため、 Factory のメンテナは Factory 内にステージングプロジェクトと呼ばれる特殊なプロジェクトを作成し、 Factory をこれらの新しいパッケージに対して構築するように決定します。アプリケーションの開発者は、中枢パッケージが Factory 本体に統合されるまでの間、発生した問題を修正することができます。
ステージングプロジェクトは、 Factory からの派生 (fork) とみなすことができますので、開発者は異なるパッケージに対する変更や更新を準備することができるほか、それらが全てうまく動作するように、構築してテストを実施し、 Factory に取り込んでもらうようにすることができます。
Factory は 3 つのリング (0-ブートストラップ, 1-最小限の X 環境, 2-テスト DVD) に分割することができます。最も内部のリング (0-ブートストラップ) には最も基本的な最小限のシステムが含まれます。リング 1 にはリング 0 に加えて、 X Window System が動作するために必要なパッケージが追加され、最も外側のリング (2-テスト DVD) には左記以外の全てが含まれます。
内側に属するパッケージに対して submit (送信) 要求が行なわれると、要求は自動的にステージングマスターに対するバックログ内に配置され、レビューと特定のステージングプロジェクトへの割り当てが行なわれます。現時点では 10 種類のステージングプロジェクト (A, B, C, D, E, F, G, H, I, J) があり、それぞれ目的と含まれるパッケージが随時変化します。ステージング J は特殊なケースで、リングに含まれないパッケージ (たとえば新しいパッケージなど) をテストするために用意されています。 ISO のインストールイメージはそれぞれのステージングプロジェクトに対して定期的に作成され、作成されたイメージは openQA の元でテストが行なわれ、現在の Factory でうまく動作しないものがないことを検証します。
この submit 要求で他のパッケージの構築に支障がある場合がありますが、このような場合は、これらのパッケージを同じステージングプロジェクトに追加して構築し、動作を確認します。
ステージングプロジェクト内にある全てのパッケージの構築が正常終了し、 openQA によるテストにも問題がない場合、 Factory メンテナは Factory 内にステージングプロジェクト内のパッケージを送信し、ステージングプロジェクトを解放します。
osc-plugin-factory はステージングプロジェクトに関連する全ての処理に対応できるツールです。 ステージングプラグインのドキュメント (英語) では、このツールの使用方法を説明しています。
開発プロセスの概要
完全な開発プロセスは このページ に書いてあります。開発プロセスは、下記の流れで行われます:
- ロードマップと機能の計画 は、ロードマップの初期版を作成するリリースマネージャが管理します。それと同時に、開発者はリリース日、および機能凍結日をベースにして、ディストリビューションの技術的なゴール地点を設定します。
- 次に OBS home プロジェクト ([8]) 内で、 パッケージ開発 が始まります。パッケージの開発者は、だれにも邪魔されることなく作業を行なうことができます。パッケージの開発が一段落すると、 devel プロジェクトに対する送信要求を行なうことができます。
- 次にプロジェクトメンテナの監視のもと、 Devel プロジェクトとの統合 が行なわれます。プロジェクトメンテナは送信要求に対して技術的な品質チェックを行ない、 devel プロジェクト全体の状態を監視する役割があります。統合が成功すると、プロジェクトメンテナは Factory に対して送信要求を行ないます。
- レビュープロセス では、すべてのパッケージに対して下記に示す 4 つ (場合によっては 5 つ) のチェックを実施し、 Factory に送信して良いものかどうかを判断します:
- Factory との統合 は Factory メンテナとリリースマネージャが管理する作業です。彼らは様々な devel プロジェクトから Factory への送信要求を受け付ける [9] 役割を担っています。彼らは主にタイミングやポリシーなどの要素を基準にした判断を行ないます。たとえばレビュープロセス完了後に品質保証の目的で宣言される機能凍結 (フリーズ) などが基準になります。また、場合によってはステージングプロジェクトの必要性を決定する場合があります。ステージングプロジェクトが必要な場合、送信要求は openQA のチェックを受けて、すべてのチェックに合格しなければならなくなります。ここまでのすべての作業が完了すると、 Factory メンテナはステージングプロジェクトを受け入れ、そこに属するすべての送信要求を Factory 内に取り込みます。
- 品質保証プロセス (openQA) は終始行なわれている作業です。 OBS は定期的に ISO イメージを生成し、事前に設定されたテストを実施します。ここで何らかの問題が発生すると、その問題に対するレポートが生成され、 ISO イメージを指し示すようになります。現時点では、 openQA は主に ステージングプロジェクト と Factory-ToTest のイメージに対して行ないます。
- Factory-ToTest 現在の Factory モデルでは、 Factory-ToTest は複数の Factory スナップショットが保存されている プロジェクト で、それぞれが openQA の品質チェックにかけられるリリース候補になっています。
- リリースプロセス タイミングと QA の品質チェックの結果に従い、リリースマネージャはマイルストーンやベータ版を公開します。リリースマネージャはリリース作業に注力する作業者で、 ISO イメージの MD5/SHA1 ハッシュの計算やリポジトリの準備、ミラーサイトの準備やそれらへの配布、製品の配置やマーケティングチームの作業開始などを行ないます。
- 公開テスト はマイルストーンリリースで行なわれる作業で、一般的に仮想マシンなどではなく実際のハードウエアにインストールしたりして確認を行ないます。
ベータ版 (全体機能凍結 (フリーズ) 前の最終マイルストーン) のリリースが行われると、間もなくリリースチームは Factory からリリース版を分岐 (fork) させ、リリースを安定させるための メンテナンス更新プロセス に入ります。
- openSUSE の開発プロセスについて、より詳しく知りたい場合は こちら をお読みください。
- リリースプロセス にもより詳しい情報があります。
- 上記で使われている各種用語については、 用語 をお読みください。
管理モデル
バグ修正と新しい機能は、まず開発 (devel) プロジェクトに対して送信し、その後 openSUSE Factory プロジェクトに送信します。このような構成により、 Factory プロジェクトの管理は細かく分解できるようになっています。
責任範囲
| パッケージ | 開発 (devel) プロジェクト | Factory |
|---|---|---|
| メンテナ (Maintainer) およびバグ所有者 (Bugowner) | プロジェクトメンテナ (Project Maintainer) およびバグ所有者 (Bugowner) | リリースチーム |
役割と責任範囲について、詳しくは こちら をおよみください。
エスカレーション
多くの決定事項は、パッケージのメンテナ (整備担当者) が実施します。メンテナが決定できないような場合や、複数のメンテナ間で解決できない矛盾が発生した場合は、開発 (devel) プロジェクトのメンテナが決定します。開発 (devel) プロジェクトのメンテナでも決定できない問題や、矛盾が発生したような場合は、 openSUSE のリリースチームがそれを決定します。リリースチームでも決定できない場合は、 openSUSE Board (委員会) にかけられ、関連する全ての人々に対する決定を促します。それでも決まらない場合は、 openSUSE Board (委員会) が投票を実施し、最終的な決定を行ないます。
メンテナ (整備担当者) ==> 開発 (devel) プロジェクトのメンテナ ==> openSUSE:リリースチーム ==> openSUSE:Board ==> openSUSE:メンバー 投票
openSUSE/Factory の開発プロセスについて、詳しくは こちら をお読みください。