Debianのリリースマネージャ、Etchの進捗を率直に語る

Debian憲章(Debian Constitution)にはリリースマネージャについての記述はないが、特にリリース準備の最終段階において、これほど影響力を持つ地位はDebianプロジェクトにはほとんどない。Steve Langasek氏とともにDebianのリリースマネージャを務めるAndreas Barth氏が最近、暫定的に12月上旬に予定されているEtchリリースの調整活動で忙しいなか、リリースプロセスの各段階、来るべきリリースの目標、役割を果たすにあたって直面している短期的および長期的な問題について語ってくれた。最悪の事態を危惧する一部の予想に反し、彼が話してくれたのは、しばしば賞賛されるオープンさを犠牲にすることなく順調な進展を見せるディストリビューションの様子だった。

Etchに取り組むDebianのリリースチームの陣容は、たいていの企業であれば大きな部門1つに匹敵する。リリースマネージャ2名に加えてリリースアシスタントが5名、そのほか少なくとも20名が品質保証、インストール関連の作業、リリースノートおよびドキュメントの作成に携わっている。

Barth氏は次のように説明する。「リリースチームは、Debianのすべての要素がリリース可能な状態にあることを確認しなければならない。その活動には、メンテナとのやりとり、リリース前に修正すべきバグを決める人々の支援(ときには損害を被るリスクを避け、重要性の低いバグの除去を後回しにすることがある)、作業もれがないことの確認などが含まれる」

また、このリリースプロセスにはDebianの関係者が総動員される。Barth氏は「Debianコミュニティのほぼ全員が何らかの形で関わっており、まずはパッケージメンテナが一斉に各自のパッケージがすべてリリース可能な状態になっていることを確認することから始まる。リリース作業は、プロジェクト全体の共同作業だ」と話している。

Debianのリリースには2,000もの人々の作業のとりまとめが必要になる、とBarth氏は見積もっている。こうした調整が面倒なのは、リリースに向けた作業が離れた場所にいるボランティアたちによって進められ、リリースチームには協力を促す手立てがないからである。ほとんどの場合、リリースチームはサンプルを設定することで手本を示す。Debianコミュニティの人々について、Barth氏は次のように語っている。「彼らはリリースの実現を心待ちにしているので、我々の意見に耳を傾けてくれるし、他のメンバーも同じ態度で臨んでいることを知っている」

必ずしも効率的ではないにせよ、こうしたやり方がうまくいっているのは、Debianコミュニティの全体的な方針との整合がとれているからである。「Debianの組織統制モデルは‘正しいことを実行すること’と‘役割を持つ者は誰でも意思決定ができること’の2点にほぼ集約される」とBarth氏は言う。つまり、リリースチームは自分たちが責任を担って活動できる程度には協力を得ているわけだ。

リリースの各段階

ある意味で、Debianリリースの準備は継続的な作業である。Debian開発者たちにより、新たなパッケージやアップグレードされたパッケージが絶えず不安定版(unstable)のリポジトリに追加される。10日経っても重大なバグが報告されなかった不安定版パッケージは、ほかのパッケージへの影響がない限り、テスト版(testing)のリポジトリに移される。ただし一般的に言って、各パッケージは、マイナーまたはメジャーの新しいバージョンのディストリビューションが用意されて初めて、Debianの現行の正式リリース版を意味する安定版のリポジトリに入ることになる。

メジャーリリースの準備にあたっては「パッケージ群を安定させるために上流での新たな変更の抑制を行う」とBarth氏は話している。第1段階として、リリースチームは「ソフトフリーズ(soft freeze)」を宣言し、まずはコアパッケージ群を対象として、どんな変更も普段以上に慎重に行うようにメンテナたちに呼びかける。最終的には「フルフリーズ(full freeze)」が宣言される。これは、変更の1つひとつに、リリース基準の一覧に照らしたリリースチームによるレビューが必要になることを意味する。今のところEtchリリースはソフトフリーズの段階にあるが、重大なバグの数が減ってくればフルフリーズに移行することが予想される。

パッケージの準備が整ってくると、その他の活動も開始される。インストールプログラムも用意されるが、Debianの前回リリースでは、新しいインストーラが開発されていたためにこの作業が特に重要であった。今回、グラフィカルなインストーラが導入されることを考えると、Etchでもこのインストールプログラムの準備は同じくらい重要になると予想される。そのほか、今回のリリースでサポートされる各ハードウェアアーキテクチャ用のRC版の準備も必要になり、リリースノートやドキュメントの作成および更新も行わなければならない。

こうしたプロセス全体を通じて、リリース版はすべてのアーキテクチャ上で何度もテストされる。Debianには公式な品質保証のサブプロジェクトが存在するが「各種基準が満たされていることをテストする方法は何種類も存在する」とBarth氏は言う。たとえば「アーカイブを調べて何か問題があれば通知してくれるツールがあったり、テスト版および不安定版の各リポジトリの運用やバグの報告をする人々がいたりする。なかにはパッケージがコンパイル中かどうかをチェックする人々もいるし、重要なパッケージにはたいていテストケースが用意される」

バグの数がリリースチームが許容可能と考えるレベルになったときに限り、RC版やそれ以降の正式リリース版の発表が行われる。許容可能なバグの数はゼロが理想的だが、実際には、主要パッケージに最小限の重大バグが残っているのが普通である。こうした妥協がなければ、時代遅れになってしまうくらいにリリースが延期されかねないからだ。

リリース目標

調整の問題を加えるにあたり、Debian Etchのリリースチームでは目標を2つに分類している。リリースを遅らせてでも達成すべき抑止性目標(blocking goal)と、対処するのが望ましいがリリースを遅らせるほど重要ではない非抑止性目標(non-blocking goal)である。

Etchの場合、抑止性目標のうち2つはソフトウェアの移行に関するもので、それらはGNU Compiler Collectionの3.3から4.0へのバージョンアップと、XFree86からX.orgへ切り替えである。前者では、Etchリリースを正しくコンパイルするためにC++ライブラリの変更が数百のパッケージで必要になる。また後者は、現行の安定したバージョンからアップグレードするユーザにとっては困難になる可能性がある。その他、抑止性目標には、AMD64アーキテクチャ向けリリースの追加、どのドキュメントがDebianにおける自由の定義を満たすかの判断 ― 何よりも、GNU Free Documentation Licenseの下でリリースされ、不変条項を持たないために含めることが可能なドキュメントを、削除しなければならない不変条項を持つドキュメントから分離すること ― が含まれる。

Etchの非抑止性目標としてはLinux Standards Base 3.1による認証や、SE Linux、普及しているIPv6、Large File Support(LFS)の各サポート、NFSRvへの完全対応が挙げられる。

各種の問題

こうした目標の達成はどんな状況であれ相当に困難だが、Etchリリースの準備は数々の問題によってさらに複雑化している。

まず、とてもよく知られたディストリビューションの1つとして、Debianはプロジェクトの発展に適した新たな構造を見つけ出そうともがいている最中である。ただでさえ政治色の強いDebianコミュニティだが、今回のEtchリリースの準備はいつも以上に不穏な状況下で進められているようだ。報酬で後押しすることがDebianの目的達成に寄与するかどうかを確めるために実験的にリリースマネージャへの報酬の支払いを提案した名だたるDebian開発者たちのグループDunc-Tankの声明は、この動きに対するプロジェクトの立場について一般決議を提起した。また関連した決議として、Dunc-Tankへの関与で利害対立の渦中にあるDebianプロジェクトリーダー(DPL)Anthony Towns氏の罷免も提案された。さらにもう1件、プロプライエタリなファームウェアに関わるカーネルファイルをメインリポジトリから除去することについても一般決議が求められた。ハードウェアサポートに穴を開けてでもDebianの思想を自由なものにしようとする動きだった。

3つの決議はどれも大変革を起こすには至らなかった。Debian開発者たちはDunc-Tankの試みを支持し、DPLの弾劾やファームウェアの排除については一切の検討をEtchリリースが終わるまで延期したからだ。現在、Barth氏はDunc-Tankのおかげで、10月にLagasek氏がそうであったように、11月中はフルタイムでリリース準備に専念している。とはいえこれら3つの決議は、歓迎されざる一面を露呈したことは言うまでもなく、事によるとDebianコミュニティを分断させかねないほどの遺恨も残した。「それでも、より小規模な組織が内部で論争している。だがDebianは別にそれらを隠してはいない」とBarth氏は言う。

また、他のフリーソフトウェアプロジェクトに起因する問題も存在する。特にBarth氏は、開発カーネルの排除に伴って「真に安定したカーネルリリースが姿を消した」こと、Mozilla Foundationが商標利用の拒否権を主張したことでFirefoxとThunderbirdの名称変更の討議が急遽Debianで行われ、結果として両者がGNU Projectによる代替のIceWeaselとIceDoveに急いで置き換えられたことを挙げている。

「どちらも‘もしそんな問題がなければ万事順調にいっていたはずだ’と言いたくなるほどひどい事態ではない。ちょっと問題が増えただけのことだ」とBarth氏は述べている。

予定通りのリリースに向けて

Etchにつきまとう最大の疑問は、これまでのDebianリリースとは違って大幅に遅れることなくリリースを完了できるかどうかである。すでにEtchのフルフリーズが一度延期されている点からすると、以前のリリース同様に予定通りには運ばないのではないかと考えられる。

Debianのリリースサイクルは長いという評判が生まれた原因の一部は、ディストリビューションに関する意思決定がオープンに行われていることにある、とBarth氏は述べている。「最初のスケジュール設定からして公に行われるため、誰にも気付かれずに見過ごせるような内密の期日は存在しない」

同時に、こうした評判は間違いではないと言わんばかりに、これまでの長いリリースサイクルはEtchにはあてはまらない、との自信をBarth氏は示している。Debianの前のリリースに言及して彼は次のように述べている。「Sargeに大きな問題があったことについては、その通りだと私は思う。だが、それは過去のことだ。Etchでは、早くから計画立案に着手し、適切なフィードバックが得られた。大半のDebianメンテナは、各自のパッケージの品質を確保する作業を予定通りに開始している。それに、リリースに向けて積極的に活動するメンバーの数が大幅に増えたこともあって、状況は良好だ。Etchがすべての点で望み通りになることはおそらくないだろうが、変革は段階を踏んで行う必要があるのだ。

Etchのリリース準備プロセスの改善を示すさらなる証拠として、Barth氏は各ハードウェアアーキテクチャが満たすべき基準の作成と、抑止性および非抑止性の分類による目標の優先順位付けを挙げている。

最後に、Barth氏は次のように述べている。「プロジェクトは順調だと思う。もちろん、Etchから学ぶべきことは色々あるだろう。我々がEtchから得た経験は、人々の意欲を高める方法について多くのことを教えてくれた。本当の責任感を与えることはそこで重要になることの1つだ。全体として、私はEtchへの取り組みに非常に満足している」

Bruce Byfield氏はセミナーのデザイナ兼インストラクタで、NewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿しているコンピュータジャーナリストでもある。

NewsForge.com 原文