openSUSE の開発および統合プロセス (詳細)

ロードマップから Beta1 まで

バージョン 1.0.3 - 29/08/2013

作者: openSUSE Team at SUSE

The Factory における開発モデルはこちらで説明しています。また、開発プロセスの概要については、こちらのページにあります。

1. ロードマップと機能の計画

目的

リリースに至るまでの初期タイムライン (ロードマップ) を作成する
新しいリリースのための主な技術ゴールを設定する

開始条件

E1.1 以前のディストリビューションのバージョンがリリースされていること。

タスク

T1.1 ロードマップの詳細の作成. このタスクは以前のロードマップをひな形として作り始めるもので、中国やドイツ、チェコやアメリカの各休暇期間を考慮して作成します。ロードマップ構築までの詳細なルール説明は [15] に書いてあります。最終的なロードマップは、 [4] にあるスキーマに従って XML で作成するものとします。ロードマップには T1.1 と T1.2 にかかわるすべての情報が記載されているものとします。この XML は SIMILE JavaScript プログラム ([5]) を利用して公開し、公式の参照として Web ページのタイムラインを作成できるようにします。また、これと並行して、ロードマップは [1] プロジェクトから wiki に公開し、リリースプロセスの間メンテナンスを実施して、マイルストーンのリリースごとに日付を見直します。なお、重要な日付 (ロードマップと機能フリーズ) は明記し、ユーザや開発者から意見を聞きやすくします。
T1.2 機能フリーズカレンダーの作成. ロードマップと並んで、カレンダーには機能フリーズに関する日付も書き込まれます ([1]) 。機能フリーズには 3 段階のステージが存在します: M3 後のツールチェインのフリーズ, M4 後の基本システムのフリーズ, そして B1 後の全機能フリーズです。 B1 の後はメンテナンスプロセスが始まります。フリーズはそれぞれの開発マイルストーンピリオドの終わりにスケジュールされ、マイルストーンのリリース後に開発のための猶予を残しておきます。また、次のリリースには近すぎない日付を設定するものとします。これは、フリーズしたコンポーネントを公開するにあたって、事前にある程度のテストを実施する必要があるためです。
T1.3 新機能の決定. メーリングリスト (アイディアや機能を議論するためのメインの連絡手段) とその他のコミュニティの連絡手段を通じて、本リリースにおける新機能を議論し、定義します。これらの機能のうちのいくつかは [6] (まだあまり使われていません) または [3] に文書化されます。新機能はコミュニティ内部 (現時点ではごく少数の参加者に限っています) で決定されるもののほか、 SLE と openSUSE の関連性から、 SUSE 内部でも決定されます。開発者は、 openFATE で SLE 向けの機能リクエストを実施することで、 openSUSE にも後から追加されるようになります (ただし、この機能は外部から参照することはできません) 。なお、 openFATE を使用するにあたっては、特に厳密なポリシーはありません。そのほか、計画や文書化無しで後から決定される機能もあります。フリーズカレンダー後、機能が実装されると、 Factory のメンテナからの明示的な承認をもって取り込みを行ないます。

確認

V1.1 ロードマップのレビュー. プロダクトマネージャ、およびリリースマネージャがロードマップを承認する必要があります。
V1.2 ロードマップのメンテナンス. ロードマップへの小さな変更は、議論無しで実施される場合があります。ただし、プロセスの遅延がリリース日に影響を与えるような場合はアナウンスを行なうほか、遅延が深刻な状況に陥っている場合は、 [17] や [18] などを利用して幅広く議論するものとします。また、 T5 に影響がある場合は、 wiki を更新します。

終了条件

X1.1 ロードマップとフリーズカレンダーがメーリングリストに公開されること。

成果物

D1.1 ロードマップを説明する XML 文書 [4]
D1.2 openFATE 内、および wiki 内に文書化された機能説明 [6], [3]

2. パッケージ開発

目的

devel プロジェクトまたは Factory プロジェクト内でパッケージを作成／更新／修正する
開発プロセスを開始するきっかけを作る
devel プロジェクトまたは Factory プロジェクト内のパッケージ間の干渉を気にすることなく、開発や実験を行なう

開始条件

E2.1 開発者が Factory 内にも devel プロジェクト内にも存在していない新しいパッケージを作成し、ディストリビューションに取り込んでもらいたいと考えていること。
E2.2 開発者が、既にディストリビューション内に存在するパッケージを更新したいと考えていること。
E2.3 Bugzilla やその他の手段で報告された、ディストリビューション内に存在するパッケージのバグに対して、開発者が修正したいと考えていること [19] 。
E2.4 以前の送信リクエスト内で、何らかのアクションを実行する必要があるメッセージが、メッセージングシステム (Hermes, [20] [21]) 内に存在すること。

タスク

T2.1 ローカルパッケージの作成. devel プロジェクトにも Factory にも存在しない新しいパッケージを作成する場合、開発者は osc コマンドラインツールか Web インターフェイスを利用して、新しいパッケージを作成します。パッケージの作成は複雑なプロセスをたどるものであるため、詳しいことは [22] に書いてあります。また、開発者が従わなければならないポリシー [23] も存在します。新しいパッケージが CPAN, Pypi, Ruby gem 内に保存されているものであった場合、パッケージの作成を支援するためのスクリプトが用意されていますが、いずれにしてもパッケージを送信するのはパッケージャの作業となります。
T2.2 パッケージのブランチ (分岐). パッケージが devel プロジェクトや Factory 内に既に存在するものであった場合、パッケージの開発者は元々のプロジェクトからパッケージをブランチ (分岐) します。ブランチではファイルのコピーに似た処理をするものではありますが、コピー先とコピー元の間での関係性が維持されます (いくつかのメタデータが保存されます) 。ただし、開発者は T2.1 に記された一般的なポリシーに従わなければなりません。
T2.3 パッケージの修正／更新. 開発者が行なう実際の作業は、このタスクに集約することができます。パッケージの開発者はバグを修正することができるほか、新しい機能を作成したり更新したりすることができます。作業が終わったら、開発者は OBS に対して変更点を送信し、 "V2.2 自動チェックが正常に終了していること" で説明しているプロセスを実施します。
T2.4 Devel プロジェクトへの送信. パッケージの作成や修正を実施し、 V2.2 が問題なく完了できると、開発者は Devel プロジェクトに対して送信リクエストを作成し、パッケージを取り込んでもらいます (Devel プロジェクトと Factory の関係性について、詳しくは用語集をお読みください) 。新しいパッケージを作成した場合など、 Devel プロジェクトがわからない場合、パッケージの開発者は opensuse-factory[47] メーリングリストに対して、適切な Devel プロジェクトを尋ねる必要があります。パッケージに対して適切なプロジェクトが存在しない場合は、 Factory のメンテナが新しい Devel プロジェクトを作成することもありますが、ほとんどの場合は既存の Devel プロジェクトを指定されることでしょう。
T2.5 自動送信. 特定のパッケージを自動的に更新するスクリプトが用意されています。これらのスクリプトは、いくつかの特定の Devel プロジェクトに対して関係してくるものであり、一般的には使用されません。このスクリプトを実行すると、スクリプトはパッケージの開発者のように振る舞い、パッケージの更新と OBS への直接送信を実施します (V2.2) 。

確認

V2.1 Factory 内に存在していること. 新しいパッケージを将来 Factory に取り込んでもらうための手順と、既に Factory 内に存在するパッケージのバグを修正したり、更新したりするための手順は異なります。この確認ポイントでは、開発者はワークフローの経路変更を明示的に決定します。
V2.2 自動チェックが正常に終了していること. それぞれのパッケージは、パッケージを構築するため、 OBS プロジェクト内にコミットされている必要があります。コンパイルが成功して作成されたパッケージがテストを通過したら、開発者は送信リクエストを作成することができます。

終了条件

X2.1 開発者が OBS のプロジェクトに対して送信リクエストを作成すること。送信リクエストはパッケージのメンテナ、もしくはパッケージの属するプロジェクトのメンテナが受け取ります。
X2.2 もしくは、開発者が変更点の送信をあきらめ、開発プロセスを中断すること。

成果物

D2.1 送信リクエスト. このリクエストはパッケージが OBS 内に正しく作成され、問題がないものとパッケージ開発者が判断したタイミングで、パッケージ開発者本人がデジタル文書の形で作成するものです。このリクエストは、パッケージのメンテナとプロジェクトのメンテナが、 devel プロジェクト内にパッケージの新しいバージョンを取り込むかどうかを判断する際に使用します。

3. Devel プロジェクトへの取り込み

パッケージが Factory に取り込まれる前に、パッケージは Devel プロジェクトに属している必要があります。 Devel プロジェクトは、ある特定の機能を含む関連パッケージの集合体です。たとえば devel:language:python プロジェクトであれば、プログラミング言語 Python に関係するすべてのパッケージを保持していますし、 LibreOffice:Stable には LibreOffice の最新安定版を保持しています。

目的

機能のリリースを取り込むなど、主な開発が行なわれる場所を提供する。
Factory に最終的に取り込む前の段階で、ある一定のレベルの品質を保証する。この取り込みのプロセスは、チェックアウト - 修正 - コミット - 送信リクエスト、のサイクルに従って行なわれます。これは 2. パッケージ開発で行なわれているものに非常に似通っています。

開始条件

E3.1 パッケージの開発者から、 Devel プロジェクトに対して送信リクエストを送信していること。
E3.2 プロジェクトのメンテナが、パッケージの変更を直接 Devel プロジェクト内で実施することを決定していること。

タスク

T3.1 送信リクエストの取り込み. プロジェクトのメンテナは、送信リクエストに対する V1 内でのレビューが完了したら、そのコードを取り込みます。一般的には、 OBS の Web インターフェイスまたは osc コマンドラインツールを利用することで実施します。パッケージのメンテナは、送信リクエストを受け入れてパッケージ内に組み込むことだけを行ないます。
T3.2 パッケージのチェックアウト. プロジェクトのメンテナが Devel プロジェクトのパッケージに対して行なう作業には、 2 つの選択肢があります。 1 つは終了条件を使用する方法で、パッケージを自分自身の home プロジェクトにブランチする (つまり、パッケージの開発者として振る舞うことのできる環境で作業を行なう) 方式です。もう 1 つは、 Devel プロジェクトから直接パッケージをチェックアウトし、必要に応じて修正する方式です。前者の方式のほうが、他の送信リクエストとの競合を気にする必要がないことから、より安全で明確な方法です。後者の方式は、メンテナや開発者が少ないプロジェクトでは適切な方法で、より高速に処理することができます。このプロセスを実施するため、 Devel プロジェクトによっては OSC のコマンドラインツールの拡張を利用してするところもあります。たとえば GNOME プロジェクトでは、より高度なワークフローを実現するため、 [24] "collab" [25] プラグインを利用しています。
T3.3 パッケージの修正／更新. 開発者が実施する実際の作業は、こちらに集約することができます。プロジェクトのメンテナもしくはパッケージのメンテナは、 Bugzilla ([19]) のバグを入力とするか、もしくはプロジェクト内で計画された機能を入力として、作業を行ないます。
T3.4 Factory への送信. パッケージまたはプロジェクトのメンテナは、メンテナンスが十分完了したと判断したら、 Factory に対して送信リクエストを作成します。

確認

V3.1 送信リクエストのレビュー. パッケージを取り込む前に、プロジェクトのメンテナ (もしくはパッケージのメンテナが別途割り当てられていれば、パッケージのメンテナ) はリクエストの内容を手作業で確認し、 spec ファイル内の問題や必要なパッチの存在、コンパイル処理内での問題などが無いことを確認します。特に問題が見つからなかった場合は、リクエストを受け入れ、実際の取り込みを行ないます (T3.1) 。何らかの問題が見つかった場合はリクエストを拒絶します。すると Hermes は送信リクエストの作成者にメッセージを送信します。また、 Devel プロジェクトによっては独自のレビュー処理が存在する場合もありますが、全体で共有されているようなポリシーはありません。
V3.2 OBS 内でのコンパイル. それぞれのパッケージを OBS にコミットします。 OBS は spec ファイル ([26]) に従ってバイナリを構築します。コンパイルが問題なく完了すると、プロジェクトのメンテナは送信リクエストを Factory 宛に作成して送信してもかまいませんし、パッケージの作業を続けてもかまいません。
V3.3 自動セキュリティレビュー. SETUID バイナリを使用するパッケージや、 D-BUS サービスや PAM モジュールを提供するパッケージの場合、自動セキュリティレビューを実施します。チェックはパッケージ作成時の rpmlint フェーズで実施され、いずれかのセキュリティポリシーに違反している ([27]) と、パッケージがコンパイルできないようになっています。このようなパッケージ構築時の制限を外してもらいたい場合は、パッケージのメンテナはセキュリティチームに対して連絡 (チケットを開く) しなければなりません。ホワイトリストに登録して制限を外してもらわない限り、 Factory には送信することができません。

終了条件

X3.1 パッケージまたはプロジェクトのメンテナが Factory に送信リクエストを作成すること。
X3.2 パッケージのメンテナは、パッケージの開発者の役割を変更するか、自身のプロジェクト内でパッケージをブランチすること。

成果物

D3.1 Factory に対する送信リクエスト。類似の送信リクエストも Factory 宛に作成して送信することができます。プロジェクトのメンテナは、複数の送信リクエストを 1 つのリクエストにまとめ、一括で受け入れまたは拒絶することができます。

4. レビュープロセス

レビュープロセスは Factory に対してのみ実施します。

目的

送信リクエストの品質を向上する。
Factory に対するリクエストの受け入れについて、可能であれば単純化する。
法律, 技術 (パッケージ内、および各パッケージ間), セキュリティの各面において、よくある問題を見つける。
パッケージが相互に依存関係を持ってしまうような問題を回避する。 Factory にコミットする前にレビューを実施することで、関連するすべてのパッケージが一定の品質水準に達しているかどうか、特定のポリシーに従っているかどうか、いくつかのパッケージが品質水準に達していないことにより、必要なパッケージを失ってしまい、 Factory の構造を壊してしまわないかどうかなどを確認することができます。

開始条件

E4.1 プロジェクトのメンテナによって、 Factory に対する送信リクエストが作成されていること ([28], [29], [30])

タスク

レビュープロセスは確認作業のみを行なうプロセスであることから、タスクはありません。

確認

V4.1 法的レビュー (legal review). 法的レビューでは 2 つのチェックを実施します: (1) スクリプト Factory-auto [10] では、パッケージ内のライセンスが変更されていないかどうかをチェックします。変更されておらず、かつライセンスデータベース内に存在するライセンスであった場合は、リクエストを受け入れます。 (2) パッケージのライセンスが変更されているか、新しいパッケージでライセンスデータベース内に存在していないライセンスであった場合は、リーガルチームがリクエストを手作業でチェックして、受け入れるかどうかを判断します。
V4.2 Factory 自動レビュー (factory-auto). Factory-auto は大まかな技術レビューを実施するスクリプト ([10]) で、リクエストでよくある問題を検出するために使用しています。たとえば、関連するパッケージが OBS 内で正常にコンパイルされているかどうかなどをチェックします。このチェックは高速に処理されるため、明らかな問題が見つかるとすぐに拒絶するようになっています。
V4.3 技術レビュー. レビューチームでは、リクエストに対するより複雑な技術要件を確認します。技術レビューでは、 spec ファイルがポリシーに従っているかどうか ([23], [26]) を確認するほか、パッチ内のコードの品質や changelog ファイル内の説明を確認します。
V4.4 リポジトリレビュー. このレビューも自動的に実行されます。このレビューは check-repo スクリプト ([10]) と呼ばれ、よくある統合時の問題をチェックすることができます。たとえば Factory プロジェクト内に特定の依存関係が存在するかどうかをチェックし、 Base:build 内には他のプロジェクトに対する依存関係が存在しないことや、 Factory 内に追加される新しいリクエストが、依存関係に問題を起こさないかどうかを確認します。

終了条件

X4.1 すべてのレビューで問題となる点が存在しないこと。
X4.1 いずれかの確認で問題が見つかった場合、リクエストは拒絶するものとします。これにより、 Hermes はリクエストの送信者にメッセージを送信します。また自動チェックでは、パッケージを完全に拒絶するほどのものではないが、それなりに問題のあるリクエストにフラグを設定します。フラグが設定された場合、送信者は何らかのアクションを起こして、終了条件に合致しているようにする必要があります。 OBS では、リクエストに対してコメントを設定する機能もありますが、こちらでも送信者に対してアクションを求めることができます。

成果物

D4.1 レビュープロセスはリクエストの状態 (作業中 (pending)、受け入れ済み (accepted)、拒絶済み (declined)) を設定します。

5. Factory との統合

目的

すべてのパッケージを 1 つのツリーにまとめて統一する。
新しい製品の ISO イメージのベースとして使用する。
Factory 内で、パッケージを機能フリーズとタイミングルールに従うように促す
Factory の他のブランチ (マイルストーン, ベータ, RC, リリース) に対して一貫性を維持させる

開始条件

E5.1 Devel プロジェクトから送信リクエストが送信され、レビュープロセスに合格していること。
E5.2 Factory のメンテナが Factory 内で問題解決を決定すること。

タスク

T5.1 Factory の監視. 定期的に Factory のメンテナは Factory 内で行なわれている作業を確認し、特に Factory メンテナの役割範囲外にあたる問題が見つかった場合は、適切な役割を持つ担当者に通知 (リマインダ) を送信するか、もしくは問題のあるパッケージを差し戻します。 Factory のメンテナは 3 種類の監視を実施します: ビルドモニタによる全プロセスの状況監視 (問題のあるパッケージが存在していないかどうか; [31] [32]), 送信リクエストのキューに対する監視 ([33]), ユーザの監視です。
T5.2 ISO イメージを生成するために OBS が使用する XML のメンテナンス. リリースメンテナは KIWI ([34]) で必要となる XML ファイルを更新および修正し、製品の ISO イメージを作成できるようにします。このプロセスに関する詳しい説明は、用意されていません。
T5.3 送信リクエストの統合. Factory のメンテナは、それぞれの Devel プロジェクトから Factory に宛てて送信された送信リクエストを受け付け、統合します。 OBS サーバに過剰な負荷がかかることを防ぐため、 Factory のメンテナは今までの経験をもとにして作られた (ただし文書化はされていません) 基本ルールに従って、受付を行ないます ([9]):
1. 新しい構築処理が動作している場合は、送信リクエストは受け付けないものとします。
2. (依存関係の中で) 枝葉となるパッケージを受け付けても、 OBS に大きな負荷はかからず、少数のパッケージのみが再構築されます。
3. 上記とは逆に、ベースパッケージや中枢パッケージを更新すると、 Factory 内の多数のパッケージに影響が発生してしまいます。そのため、これらは週末まで待ってから受け付けるものとします。
T5.4 パッケージの差し戻しまたは削除. パッケージのメンテナからの応答が無い場合、もしくはパッケージの更新などで大きな問題が見つかった場合は、変更を差し戻したりパッケージを削除したりします。
T5.5 問題の通知. Factory のメンテナは、 Factory 内のパッケージで問題が発生しているかどうかを調べ、必要であればパッケージまたはプロジェクトのメンテナに通知します。
T5.6 ステージングプロジェクトの作成. 統合のプロセスと問題の検出を単純化する目的で、 Factory のメンテナはステージングプロジェクトを作成します。ステージングプロジェクトには、新しい主要パッケージ (gcc, perl など) のほか、その依存関係にあるパッケージや関係するパッケージが含まれています。ステージングプロジェクトを作成することで、メンテナは新しいパッケージにおける問題を、他のパッケージの影響を受けずに見つけることができるようになります。
T5.7 パターンの作成. Factory のメンテナは、インストールに必要なパターン ([36]) を作成および更新します。パターンの書式と目的については、 [35], [37] をそれぞれお読みください。

確認

V5.1 Factory への送信リクエストを受け付けるかどうか？ 機能フリーズなど、送信リクエストを受け付けない理由があるかどうかを調べます。
V5.2 概要レビュー. レビュープロセスで低品質な送信リクエストを防ぐようになっていることから、 Factory のメンテナは品質に関する確認までは行ないません。その代わり、リクエストを受け付けて構築プロセスを始めるタイミングを判断します。 Factory のメンテナは、下記の基準でリクエストに対する単純なレビューのみを実施し、該当すれば拒絶または保留を決定します:
1. 送信リクエストが機能フリーズ状態にあるパッケージに関するものであるか、もしくはそれに関連するパッケージで、何らかの問題を解決するようなものではない場合。
2. パッケージが他の多数のパッケージに影響を及ぼし、ステージングプロジェクトが必要となる場合。

終了条件

X5.1 パッケージが Factory 内に統合されていること。
X5.2 パッケージを拒絶した場合は、 Hermes でイベントが報告されていること。
X5.3 バグ報告が Bugzilla 内に作成されていること。

成果物

D5.1 Factory 内に統合されたパッケージ。
D5.2 利用可能な状態になった Factory のリポジトリ。

6. 品質保証 (QA) プロセス

QA プロセスは openQA ツール ([11], [12]) を利用して自動的に行ないますが、仮想マシンや実マシンを利用して手作業で実施することもできます。

目的

T5. Factory との統合で生成された製品について、その品質を判断すること。
マイルストーンやベータ 1 版となる ISO イメージをテストすること。
ISO ビルド内に存在する現実のバグ (統合の問題やパッケージのバグ) を発見すること (修正作業はプロセスに含みません) 。
ビルドされたものの最終的な品質を定量化し、修正されるべき新しい問題を検出して Bugzilla を更新すること。

開始条件

E6.1 OBS で生成された新しい自動ビルドが存在すること。
E6.2 リリースマネージャ、もしくは Factory のメンテナが、最終的な製品の候補 (マイルストーンまたはベータ) となるビルドイメージを決定し、テストを決断すること。
E6.3 QA チームが新しい機能をテストしたり、 BNC ([19]) 内で報告されているバグを再現したりすることを決断すること。

タスク

T6.1 新しいテストの作成. 現在のテストのカバレッジ (テスト範囲) が不十分であると QA チームが判断した場合、新しい機能やユースケースをテストするための新しいテストを記述する必要があります。
T6.2 テストのメンテナンス. Factory に対するテストの作成は、 openQA を利用して行ないます。このツールでは、 needle ("針" の意味; [46]) と呼ばれる特定コンポーネントのメンテナンスを必要とします。 needle は期待通りに動作しているかどうかを確認するために使用されるもので、ディストリビューションの外観や動作に影響するアートワークなどの重要な仕様が変更された場合、更新および調整する必要があるものです。
T6.3 バグ報告の作成. opqnQA はディストリビューション内の問題を検出することができますが、 ISO イメージに影響する具体的な原因までは判別することができません。 QA のレビュアーは失敗したテストの詳細を調査し、間違っている箇所を見つけて Bugzilla にバグ報告を実施します。このバグは、 T2. パッケージ開発タスクもしくは T3. Devel プロジェクトへの取り込みを担当した適切な開発者に割り当てるものとします。

確認

V6.1 テストのレビュー. テストはいくつかの基準に従ってグループ化します: テストのフェーズ (インストール処理, テキストアプリケーション, グラフィカルアプリケーション), 相対的な重要度 (最重要, 重要, 通常) 。ツール側では、最重要なテストが正常に終了しなかった場合、もしくは特定のテストでインストール時に問題が発生したりした場合に、 ISO を失敗としてマークします。 openQA の最終結果が緑色 (正常終了) でなかった場合、 ISO はバグの調査対象となり、バグ報告を作成します (T6.3) 。

終了条件

X6.1 最重要、および重要としてマークしたテストが緑色 (正常終了) になっていて、 ISO がマイルストーンもしくはベータのリリースとして適切であると判断されること。
X6.2 いくつかの設定でツールが重要なバグを検出していて、 ISO が公開可能な候補としては拒絶されていること。

成果物

D6.1 テスト報告. アプリケーションが生成したスクリーンショットおよび状況情報付きのテスト報告。この報告は QA レビュアーがレビューします。
D6.2 バグ報告. バグ (致命的なものであっても、そうでなくても) が見つかった場合、 QA レビュアーは説明を添えてバグ報告を作成し、適切なパッケージのメンテナを割り当てます。

7. リリースプロセス

目的

マイルストーンやベータ版のイメージをテスト用に公開する ([38], [39]) 。
プロセスを完了する。

開始条件

E7.1 リリース日の 2 日前であること。

タスク

T7.1 ロードマップの更新. リリースマネージャはロードマップを調整し、各所に連絡を行ないます.
T7.2 イメージの構築. KIWI を利用することで、 OBS は XML 文書に従って ISO イメージを作成することができます。それぞれの製品 (ISO イメージ) ごとに別々の XML 文書を用意します。
T7.3 署名の生成. autobuild チームは SUSE の名前で署名を生成し、直近のマイルストーンからの差分 ISO を生成します。
T7.4 ハッシュの計算. リリースマネージャはイメージの MD5/SHA1 ハッシュを計算します。
T7.5 マーケティング用の変更履歴の作成. リリースマネージャは dvddiff スクリプトを利用して直前のマイルストーンとの間で差分を取り出し、重要な変更点とともにマーケティング宛に送付します。出力された一覧は、更新内容の重要度を基準にして適切な数 (10 個から 30 個程度) にまとめられます。
T7.6 (ベータ版の場合) ソースブランチの作成. ベータ版の場合、リリースマネージャはすべてのソースを Factory から分岐 (ブランチ) します。ブランチが作成されたら、 Factory を再度開発可能な状態にします。
T7.7 アナウンスの作成. マーケティングマネージャは、受け取った差分と progress.o.o ([40]) にあるテンプレートをもとにして、アナウンスを作成します
T7.8 ミラーサイトへのイメージ配信. リリースマネージャは、イメージとバイナリリポジトリをミラーサイト ([41]) に配信します。リリースマネージャは、ミラーサイトの管理者に対して新しい ISO が公開された旨と、公開予定日をメーリングリスト mirror@opensuse.org で通知します。リリースマネージャは、ミラーサイト向けにイメージを公開し、読み込むことができるようにします。
T7.9 ステージングの更新. リリースマネージャはステージング領域と BitTorrent 用のメタリンクを更新します。
T7.10 NPP 内での製品紹介. リリースマネージャは、 Bugzilla を利用して Novell の製品ページ内に新しいマイルストーンを公開するように依頼します。
T7.11 アナウンスの発信. マーケティングマネージャは、アナウンスを公開します。

確認

V7.1 イメージの選択. リリースマネージャは、 openQA の入力をもとにして、公開予定のイメージが十分なものであるかどうかを判断します。リリースが早期マイルストーンのものである場合、リリースマネージャは openQA の出力ではなく、異なる条件でリリースを判断することもできます。正式リリースに近づくにしたがって、リリースマネージャはリリースの条件を厳しく設定します。
V7.2 ベータ版のロードマップに関する議論. ベータ版の場合、製品マネージャとマネージメント機構との間で、 Factory の状態とロードマップの状況について議論を行ないます。最終リリースの場合は、リリースマネージャやコントローラ、 QA レビュアーや製品マネージャとマネージメント機構が参加して、公開すべきかどうか、遅延させるべきかどうかの決定を下します。
V7.3 コミュニケーションの確認. リリースマネージャは、再度の議論が必要なほど遅延しているかどうかをチェックします。
V7.4 配信状態の確認. リリースマネージャは、イメージがミラーサイトに正常に配信され、公開可能な状態になっているかどうかを確認します。

終了条件

X7.1 実際に公開され、アナウンスが配信できていること。

成果物

D7.1 対応するすべてのプラットフォームおよびアーキテクチャに対する ISO イメージ。
D7.2 news.o.o およびメーリングリスト向けのリリース文書
D7.3 遅延発生時は、その旨のアナウンスと新しいロードマップ

8. 公開テスト

リリースプロセスの後は、コミュニティ (開発者とユーザ) による第 2 の品質保証プロセスを実施します。このテストは自動で行なわれるようなものではなく、一般に実際のハードウエア内で実行してテストします。

目的

リリース後、生成された製品の品質を判断する。
実際のハードウエア、実際の用途におけるバグを洗い出す。
エラーを検出し、修正すべき新しいエラーを Bugzilla で更新する。

開始条件

E8.1 新しいリリース (マイルストーンもしくはベータ) を software.o.o ([14]) に公開していること。

タスク

本プロセスはタスクとしても確認ポイントとしても機能するものです。検証ポイントという観点では、特にタスクはありません。

確認

V8.1 実際のマシンでのテスト. ユーザ (または開発者) は software.o.o [14] からリリースをダウンロードして、実際のハードウエアにインストールします。そこで何らかの問題が見つかると、 Bugzilla ([19]) にバグ報告が作成されるか、もしくは Factory メーリングリストに報告が行なわれます。また、ユーザによってはリリースされたメディアを使用せず、 Factory を直接利用 ([50]) して更新する場合もよくあります。

終了条件

X8.1 新しいリリースが公開されていること。

成果物

D8.1 バグ報告. 何らかのバグが見つかると、テスターは説明を添えてバグ報告を作成します。 QA レビュアーはバグを再現させ、適切な開発者に割り当てます。

プロジェクトの組織

1. 役割と責任範囲

Factory の開発にあたっては多数の人々がかかわっています。当プロジェクトでは、下記の役割を認識しています:

製品マネージャ
- 機能面の計画に対して責任を負います。
- 連絡先: abebe@suse.de
リリースマネージャ
- リリーススケジュールを策定し、リリースの全フェーズを管理して必要であれば調整を行ないます。
- 連絡先: coolo@suse.de
Factory メンテナ
- パッケージ側のメンテナの代理として活動するほか、複雑な統合問題の解決を支援します。
- 連絡先: coolo@suse.de
パッケージ開発者
- パッケージを作成したり、新しいバージョンに更新して機能を追加したりします。
パッケージのメンテナ
- パッケージ内のバグを修正します。
- 既定では、パッケージの作成者が担当します。
- 既存のメンテナ (もしも既存のメンテナに連絡が取れない場合は、 Devel プロジェクトのメンテナ) は、パッケージに対して継続的な貢献と注力を期待して、新しいメンテナを追加することもできます。
Devel プロジェクトのメンテナ
- Devel プロジェクトに届くリクエストをレビューします。
スーパー Devel プロジェクトのメンテナ
- Devel プロジェクトのメンテナの代理として活動します。この役割は、すべての Devel プロジェクト内の "maintainer" (メンテナ) として登録されている、 "factory-maintainers" グループの形で設定されています。
- 連絡先: tchvatal@suse.com

いくつかの自動化ツールも用意されています:

Factory Auto
- 基本的なパッケージ標準が守られているかどうかをチェックします。
- https://github.com/coolo/factory-auto
Legal Auto
- リーガルチームによる手動レビューが必要かどうかを判断する、自動チェックです。
Factory Repo Checker
- パッケージを通過させる前に、より深いチェック (パッケージの構築状況, インストール, 競合関係など) を実施します。
- https://github.com/coolo/factory-auto

また、下記のようなチームが構成されています:

レビューチーム
- Factory に送信されるパッケージの品質の維持に責任を負います。
- Factory への送信にあたっては、ソフトウエアが正しくパッケージ化されているか、パッケージングガイドラインに従って作成されているかどうかを調べるため、このチームのレビューを必須としています。
- 説明: openSUSE:openSUSE_レビューチーム
- 連絡先: review@opensuse.org (英語)
リーガルチーム
- パッケージの配布に際して法律面の問題が無いかどうかをチェックします。
- 設定されているライセンスが正しいかどうか、および矛盾するライセンスが無いかどうかをレビューします。
- 連絡先: opensuse-bar@opensuse.org (英語)
セキュリティチーム
- 特権 (suid, ケーパビリティなど) を必要とするパッケージの場合、このチームの承認無しには Factory でその特権を得ることができません。
- セキュリティ上の問題を報告します。
- 説明: openSUSE:セキュリティチーム
- 連絡先: opensuse-security@opensuse.org (英語)
自動ビルドチーム
- SUSE の署名を作成したり、 ISO 間の差分を生成したりします。
ドキュメンテーションチーム
- ドキュメンテーションのメンテナンスに対して、責任を負います。
- 説明: openSUSE:ドキュメンテーションチーム
- 連絡先: opensuse-doc@opensuse.org (英語)
品質保証 (QA) チーム
- Factory のテストに責任を負うほか、将来のマイルストーンの評価も行ないます。
- 説明: openSUSE:中枢テストチーム
- 連絡先: opensuse-testing@opensuse.org (英語)
マーケティングチーム
- 外界とのコミュニケーションに責任を負うほか、リリースのプロモーションなども行ないます。
- 説明: openSUSE:マーケティングチーム
- 連絡先: opensuse-marketing@opensuse.org (英語)

Open Build Service 内では、これらの役割のうちの 1 つ以上が割り当てられます。詳しくは [42], [43], [44], [45] をお読みください。

用語集

ブランチ

貢献者がパッケージに対して作業を行なう際、貢献者はまず元のパッケージのコピーを作成するところから始まります。 OBS では元のパッケージとコピー先のパッケージ (ブランチパッケージ) との間の関係性を設定し、マージ (統合) プロセスがうまく動作するようにします。

BNC

Bugzilla をお読みください。

Bugzilla

バグ報告を収集し、監視し、担当者を割り当て、更新するための管理ツールです。本プロジェクトでは、 Novell が提供する Bugzilla ([19]) を利用しています。略して BNC とも呼びます。

コミット

開発者 (貢献者) がパッケージに対して作業を行なう際、最終的に変更点を登録する必要があります。この登録処理をコミットと呼びます。 OSC コマンドラインツールや Web インターフェイスを利用することで、コミットを実施することができます。

Devel プロジェクト

Factory のアップストリーム (提供元) となるプロジェクトを意味します。 Factory は様々な Devel プロジェクトが提供するパッケージから構成され、次期リリース版を構築するための統合体として機能しています。 [48] には、 Devel プロジェクトに対するより正確な説明が書かれています。 Devel プロジェクトには 1 人以上のメンテナが割り当てられていて、そのパッケージに対する機能実装 (ロードマップ) とプロジェクトへの統合作業を実施します。

ETVX

1985 年に IBM が制定した、ソフトウエア開発プロセスの方法論です。この方法論は図 (フローチャート) を多用する方式ではなく、より文章的な開発手法として知られています ([13]) 。

Factory

Factory は OBS 内に用意されているプロジェクトのうちの 1 つで、最終的に openSUSE のリリースとなるため、様々な Devel プロジェクトからのパッケージを統合します。 Factory 内での作業は通常、 Factory メンテナ (様々なプロジェクトパッケージの統合) とリリースマネージャ (Factory が提供するパッケージをベースにした ISO イメージの作成) が実施します。

機能フリーズ (Feature Freeze)

Devel プロジェクトと Factory との統合を容易にするため、リリースマネージャは特定のパッケージについて更新を許可する期限を決定します。期限が経過すると、リリースマネージャと Factory のメンテナは、新しいリリースサイクルが始まるまで、バグ修正だけを許可し、新しいバージョンや新しい機能などの追加を禁止するようになります。もちろん例外もあります。

Hermes

Hermes [21] は openSUSE プロジェクトにおける中枢通知ハブです。受信したい通知の種類を選択したり、通知方法や時期を設定したりすることができます。

ホームプロジェクト

それぞれの開発者に対して、他のユーザから干渉されることなく開発したり、実験したりするための独自のプロジェクトが用意されています。これをホームプロジェクトと呼びます。 Devel プロジェクトや Factory からパッケージを分岐 (ブランチ) させると、コピーされたパッケージがホームプロジェクト内に用意されるようになります。

KIWI

openSUSE KIWI [34] イメージシステムは、 Linux の動作するハードウエアプラットフォーム向けのオペレーティングシステム完全イメージソリューションです。 Xen, Qemu, VMware などの仮想化環境でも利用することができます。

OBS

Open Build Service (OBS) [8] はソースコードから自動的に、一貫性と再現性のある方法でバイナリパッケージを構築し、配布するための汎用システムです。更新やアドオン、アプライアンスやディストリビューション全体の配布時にも使用されているシステムで、幅広いオペレーティングシステムとハードウエアアーキテクチャに対応しています。

openFATE

openFATE [6] [7] は openSUSE コミュニティにおける新機能／新要件の管理システムです。すべての openSUSE メンバーに対して、製品の計画をオープンに管理するために使用されています。

openQA

openQA [11] を利用することで、ディストリビューションに対するテストを自動的に実施することができます。テストによっては、様々なファイルシステム設定やデスクトップ環境、またはアーキテクチャやメディアなどを設定して、仮想 (または物理) マシンに対してフルインストールを実施するものもあります。

OSC

OBS と通信するためのコマンドラインツールです。

パッケージ

ソースパッケージとは、ファイル (通常は tar ファイルのほか、パッチファイルなどのリソース類) と spec ファイルが同梱されているファイルで、 1 つまたは複数のバイナリパッケージを構築する際に使用されるものです。

パターン

特定の構成や機能を集めたパッケージ集のことを言います。パターンは、よくある構成 (ラップトップ、サーバ、デスクトップ、開発、オフィスユーザなど) で使用されるパッケージを一括でインストールする際に利用されるものです。

プロジェクト

ソースパッケージを保持するコンテナです。

リポジトリ

バイナリパッケージのコンテナです。それぞれのアーキテクチャごとにコンパイルされたバイナリパッケージをテストします。

ロードマップ

短期、もしくは長期のゴールを設定した計画で、最終的なゴールにたどり着くための技術的な解決手法を示すものです。

ステージングプロジェクト (Staging Project)

Factory に送信される前に、最重要なコンポーネントをテストするために使用する一時的なプロジェクトです。ステージングプロジェクトは Factory のメンテナが必要に応じて作成したり削除したりするもので、 [49] などいくつかのプロジェクトは定期的に再利用されます。

送信リクエスト (Submit Request)

開発者が作成し、 OBS が管理するリクエストで、ソースパッケージに対する変更点を説明した電子文書のことを言います。

参照

[1] openSUSE ロードマップ: Roadmap (日本語), http://en.opensuse.org/openSUSE:Roadmap (英語)

[2] openSUSE のゴール: http://en.opensuse.org/openSUSE:Goals_13.1 (英語)

[3] openSUSE の機能: https://features.opensuse.org/statistic/product/opensuse_131 (英語)

[4] XML ロードマップ: http://turing.suse.de/~coolo/opensuse_13.1/opensuse.xml (英語)

[5] ロードマップの SMILE ビュー: http://turing.suse.de/~coolo/opensuse_13.1/ (英語)

[6] openFATE: https://features.opensuse.org/ (英語)

[7] openFATE の説明: openSUSE:Openfate (日本語), http://en.opensuse.org/openSUSE:Openfate (英語)

[8] Open Build Service (OBS): https://build.opensuse.org/ (英語)

[9] Factory リリースプロセス: openSUSE:リリースチームのプロセス (日本語), https://en.opensuse.org/openSUSE:Release_team_processes

[10] Factory-Auto とその他のスクリプト: https://github.com/coolo/factory-auto (英語)

[11] openQA: http://openqa.opensuse.org/ (英語)

[12] openQA (内部リンク): http://opensuseqa.suse.de/ (英語)

[13] ETVX モデル: Radice, R.A.; Roth, N.K.; O'Hara, A.C., Jr; Ciarfella, W.A. " A Programming Process Architecture" IBM Systems Journal Vol.24, No 2 (1985), pp.79-90.

[14] Software openSUSE (開発バージョン): http://software.opensuse.org/developer/ja

[15] ロードマップ (openSUSE 12.2 レポート): https://wiki.innerweb.novell.com/index.php/OpenSUSE_team_report_12.2#Schedule (英語)

[16] OBS チュートリアル: openSUSE:Build Service での共同作業 (日本語), https://en.opensuse.org/openSUSE:Build_Service_Collaboration (英語)

[17] 遅延アナウンス: http://news.opensuse.org/2012/06/14/where-is-my-12-2-my-kingdom-for-a-12-2/ (英語)

[18] 遅延の分析: http://lists.opensuse.org/opensuse-factory/2012-06/msg00468.html (英語)

[19] Bugzilla Novell: http://bugzilla.novell.com/ (英語)

[20] Hermes: https://hermes.opensuse.org/ (英語)

[21] Hermes の説明: openSUSE:Hermes (日本語), http://en.opensuse.org/openSUSE:Hermes (英語)

[22] OBS 内でのパッケージ作成: openSUSE:Build Service チュートリアル (日本語), http://en.opensuse.org/openSUSE:Build_Service_Tutorial (英語)

[23] パッケージポリシーとガイドライン: openSUSE:パッケージングガイドライン (日本語), http://en.opensuse.org/openSUSE:Packaging_guidelines (英語)

[24] OBS プラグイン: openSUSE:OSC プラグイン (日本語), http://en.opensuse.org/openSUSE:OSC_plugins (英語)

[25] OBS プラグイン集: openSUSE:Build Service ツール (日本語), http://en.opensuse.org/openSUSE:Build_Service_Tools (英語)