目次
Free Software における品質改善: リリース管理を中心に
この文書について
- "Quality Improvement in Free Software: Release Management" の日本語訳です.
- 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか...
- 原文がまだ完結していません. 続きが登場次第追加してきます(たぶん).
- Open Tech Press の関連記事
Free Software における品質改善: リリース管理を中心に
私の博士課程はもうすぐ終わる. その研究成果のことを書き始めたところだ.
この博士課程では, free software のプロジェクトにおける品質改善について調査しようと努めた.
free software の品質について少し調べてまわったあと,
私はリリース管理に話題を絞ろうと決めた.
この分野には問題があって, そのプロセスは改善できると思ったからだ.
その改善によって, free software のプロジェクトによる成果物の
品質水準を引き上げることができればと期待している.
リリース管理を調べるにあたり, 大きく複雑なプロジェクトをもっぱら焦点とした.
そうしたプロジェクトでは, リリースの準備にあわせて
数百人のボランティアが協調しなければいけない.
私が特に注目したのは時間ベースのリリース管理だ.
予備調査によると, この種のリリース管理戦略には大きな関心が寄せられている.
私の研究が問うのは主にこういうことだ.
時間ベースのリリース管理は, どのように,
なぜ, 巨大な free software のプロジェクトで役割を果たしているのだろうか.
最初の投稿では free software のプロジェクトを 7 つ紹介していく.
私は研究のなかでこれらのプロジェクトを注意深く調査した.
各プロジェクトごとにこれまでの問題を簡単にまとめ,
その問題に対処すべく行われたことを示す.
それから今なお解決していない問題が何かを述べていく.
Debian
Debian プロジェクトの目的は,
他のプロジェクトが作ったソフトウェアを統合して
free software を基盤とする完全なオペレーティング・システムを作ることだ.
過去数年, プロジェクトは広がり続ける遅延と予測不能なリリースという問題を抱えてきた.
特筆すべきは Debian 3.1 のリリース・プロセスで,
これは重大な遅延だとみなされている.
当初 2003 年 12 月 1 日リリースと発表されていたソフトウェアは,
結局 2005 年 6 月にリリースされた. 一年半に及ぶ遅延だ.
それ以来, プロジェクトではリリース・プロセスに関するいくつもの改善がなされた.
| Version | Date | Months |
| 1.1 | 1996-06-17 | - |
| 1.2 | 1996-12-12 | 6 |
| 1.3 | 1997-06-02 | 6 |
| 2.0 | 1998-07-24 | 14 |
| 2.1 | 1999-03-09 | 7 |
| 2.2 | 2000-08-14 | 17 |
| 3.0 | 2002-07-19 | 23 |
| 3.1 | 2005-06-06 | 35 |
これまでの問題
- リリース管理はあまり組織化されておらず, リリースの更新はたまにしか実施されなかった. こうした問題とロードマップの欠如から, 凍結(コード・フリーズ)の発表が唐突にされることも多かった.
- 組織化されていないリリースの常として, 新しい予定外のブロッカーがリリース・プロセスでみつかった. それも遅延を招いた.
- 予定外の遅延があると, ソフトウェアは長期にわたって凍結される. Debian 3.1 の場合は一年以上凍結された. このリリースが公開に至った時にはすでに多くのコンポーネントが古くなってしまい, ユーザの要望に合わなくなっていた.
- Debian が過去のリリースで何度も深刻な遅延に至ったという事実は, プロジェクトのイメージを損ねた. Debian は進みが遅く締切を守れないと思われている. これは開発者やユーザ・コミュニティの不満にもつながっている.
対策
- プロジェクトはより良いリリース管理の構造を備えるようになった. Debian のリリース管理者は一人だったが, 3.1 のリリース期間ではチーム構成になった. 現在は二人の管理者がリリースの面倒を見ており, 複数人のリリース補助がそれを手伝っている.
- 次のリリース時期は前もって設定されるようになり, もっと計画的になった.
- リリース関係の発表はより頻繁に送信されるようになり, 情報源も複数用意された. そうして開発者へリリース状況を周知できるようになった.
- リリース目標がよりきちんと定義されるようになり, ブロッカーとゴールが区別された. ブロッカーだけはリリースに間に合わせるが, ゴールは将来のリリースに先送りできる. たとえば Debian 4.0 だと , XFree86 から X.org への移行と AMD64 サポートの統合はブロッカーであり, LSB3.1 互換 と SE Linux のサポートはゴールにすぎない.
- リリース・チームは目標を達成するという責務を個々の開発者やチームに移した. またこの責務を判断するよりよい基準が定義された. たとえば, Debian 4.0 で使えるアーキテクチャを定めた基準が公開されている.
- リリース・チームは開発者に対し, 専門外のパッケージにあるバグ修正も勧めるようになった.
- 分類つき凍結が実施された. ソフトウェアの重要度によって凍結時期を分けている. ツールチェインやベースのシステムはマイナーなパッケージより早い時期に凍結する. 現在はブロッカーがほぼ片付いた時点で大半のソフトウェアを凍結する.
- 実験用レポジトリの利用が推進されるようになった. おかげでメインの開発レポジトリはほぼいつでも良い状態にある.
残った問題
- 目標の到達度, 締切は現実的か, Debian は予定どおりにリリースされるのかについてなどは, 今でも開発者に対して念を押す必要がある.
GCC
The GNU Compiler Collection (GCC) は C や C++ など複数のプログラミング言語を
サポートするコンパイラ・スイートである. これは free software のプロジェクトにとって
極めて重要な開発ツールとなっている.
90 年代に EGCS プロジェクトが結成されるまで, GCC は動きのないプロジェクトだった.
1998 年 10 月, EGCS は公式の GCC 開発に乗り込み,
高度なピアレビューなどの確固たるプロセスを打ち立てた.
また運営委員会を設置した. 委員会はメンテナを探したり, 重要な意思決定を行った.
計画では, プロジェクトは 6 ヶ月間隔で時間ベースのリリースを行うはずだった.
実際には, ここ数回を見るかぎり毎年ひとつの新バージョンをリリースするに留まっている.
| Version | Date | Months |
| 3.0 | 2001-06-18 | - |
| 3.1 | 2002-05-15 | 11 |
| 3.2 | 2002-08-14 | 3 |
| 3.3 | 2003-05-13 | 9 |
| 3.4.0 | 2004-04-18 | 11 |
| 4.0.0 | 2005-04-20 | 12 |
| 4.1.0 | 2006-02-28 | 10 |
これまでの問題
- かつての GCC プロジェクトは閉鎖的な開発スタイルに陥っていた: コードを変更できるのは数人だけで, メーリングリストは招待制だった.
- 開発版のスナップショットとリリースが長時間乖離していた. 開発版にあるバグ修正や機能は公開されていなかった.
- 開発が始まると, コードの大変更が頻繁に行なわれた. これは安定フェーズに時間がかかった.
対策
- プロジェクトはよりオープンなスタイルに移行し, 運営委員会を設置した. 委員会は新しいメンテナを探したり, 重要な意思決定を行った.
- 開発を 3 つのステージに分割した. コードの投稿を管理し, 開発ツリーをほどほどに安定させるためだ. 開発者が大変更をしたい時はステージ 1 を使う. ステージ 2 については プロジェクトの wiki で提案をする必要がある. 提案はリリース管理者がレビューする. リリース管理者は提案に順番をつけて, 各提案をいつ開発ツリーに適用できるかを指示したりもする.
- 全てのパッチは開発者メーリングリストでレビューされ, 適用するには許可が要るようになった. 運営委員会はパッチのあたる分野に許可をだせるメンテナをつかまえる. C フロントエンドのメンテナ, 各種移植のメンテナ, そのほかのメンテナなどがいる.
- 各開発ステージは二ヶ月つづく. したがって理論的には 6 ヶ月毎にリリースできる. 定期的なリリース間隔が保障されていると, ある機能が次のリリースに入らなくても世界の終わりという風にはならなくなる.
残った問題
- リリース管理者が多忙で, 本来あるべきよりもリリースに向けた作業を進めていない.
- ブランチ基準の改訂 (revision) が必要かもしれない. そうすると次回の安定版につながるブランチを切るのが簡単になる. 現在のブランチ基準では 100 近くの回帰テストを開発版のツリーに適用することになっているが, この数にはおそらく以前のリリースにもあった回帰テストも含まれているため, この基準を満たすのは極めて難しくなっている.
GNOME
GNOME は簡単に使える完全なデスクトップ環境を提供している.
このプロジェクトはいくつかの大きな問題に直面してきた.
1.x 系や 2.0 のリリースの準備に関する遅延などがそうだ.
GNOME は 2.0 以降から時間ベースのリリースを採用し, リリース管理を著しく改善してきた.
プロジェクトはここ数年 6 ヶ月毎に時間ベースのリリースを行っており,
これは時間ベースのリリース管理の手本だと見られている.
| Version | Date | Months |
| 1.0 | 1999-03-03 | - |
| 1.2 | 2000-05-25 | 15 |
| 1.4 | 2001-04-02 | 10 |
| 2.0 | 2002-06-27 | 15 |
| 2.2 | 2003-02-06 | 7 |
| 2.4 | 2003-09-11 | 7 |
| 2.6 | 2004-03-31 | 7 |
| 2.8 | 2004-09-15 | 6 |
| 2.10 | 2005-03-09 | 6 |
| 2.12 | 2005-09-07 | 6 |
| 2.14 | 2006-03-15 | 6 |
| 2.16 | 2006-09-06 | 6 |
| 2.18 | 2007-03-14 | 6 |
これまでの問題
- バージョン 2.0 の主要な目標は内部インターフェイスの変更だった. しかし一年以上開発をしてから, もっとユーザから見える部分の変更をすべきだと感じるようになった. それが遅延を招いた.
- 開発者は遅延に落胆し, 変更がユーザに届かないことを残念がった.
- 何が起きているのかがはっきりしなかった. 開発者はリリースの状況について何度も問い合わせをした.
- 凍結が発表され, 人々が準備を始めてからその凍結が遅延された. また予期せぬ凍結も頻繁におこった.
- ベンダには締切があるのに, GNOME のスケジュールは予測不能だった. 新しいバージョンに備えるべきか, 前のバージョンに集中して修正をバックポートすべきか, ベンダにはわからなかった.
- ベンダは GNOME が古いとみなしているバージョンに多くの変更をバックポートしなければならなかった.
対策
- プロジェクトは 6 ヶ月毎のリリースを約束する堅いスケジュールを導入した.
- コアチームがあったので, スケジュール導入の同意をとりつける手間はほとんどなかった.
- 開発ツリーをきちんと安定させておく方針を導入した.
- 巻き戻しという考えを導入した. ある機能が期日に間に合わなそうなら, それを取りやめるというもの.
- プロジェクトは信頼を得た. リリースが時間どおりに行われたからだ.
- スケジュールのおかげでベンダは良い計画を立てらるようになった. また, ベンダは自分達の機能をメインの開発ツリーに実装することができた.
残った問題
- 6 ヶ月のスケジュールは見事にインクリメンタルな更新を実現した. 懸念として, このリリース間隔のせいで GNOME 3.0 に向けた大きな変更が革新的, 野心的でなくなっているのではというものがある.
Linux Kernel
Linux Kernel のプロジェクトは, 過去数年でそのリリース戦略を大きく変えてきた.
2003 年 12 月, 2.6 系の最初の安定版のリリース以降は特に違っている.
この 2.6 系は, 2001 年 1 月に 2.4 系がリリースされてから 3 年近く開発が続いた.
多くの人がこれを長過ぎると感じていた.
メジャーリリースの間隔の長さから来る弊害の一つは,
ベンダがバックポートやフォワードポートを大量にパッチしなければいけない点にある.
カーネルの新しい開発モデルは多数の非難を受けている.
人によっては, 特にカーネル開発者はこの方法でうまく言っていると主張するが,
利用者の中にはカーネルに対する大改造の多さと安定性の欠如に不安を感じている人もいる.
開発者のリードである Andrew Morton は,
カーネルがバギーになりつつある旨を数回に渡り表明している.
| Version | Date | Months |
| 1.0 | 1994-03-14 | - |
| 1.2 | 1995-03-07 | 12 |
| 2.0 | 1996-06-09 | 15 |
| 2.2 | 1999-01-25 | 31 |
| 2.4 | 2001-01-04 | 23 |
| 2.6 | 2003-12-17 | 35 |
これまでの問題
- リリース間隔が長いために多くの変更が集積してしまった. 開発を安定させるのは難しく, テスターもほとんどいなかった.
- 機能の増加が遅かった. これもリリース間隔の長さによる.
- ハードウェアのサポートや重要な機能は最新の安定版にバックポートされた.
- ベンダは独自リリースに多くの機能をバックポートした. 異なるベンダ同士のコードベースには隔たりがあり, 公式バージョンとも離れていた.
対策
- 現在, 新バージョンは 2, 3 ヶ月毎にリリースされている. 各リリースには 2 週間のマージ期間があり, その間に新機能が受け入れられていく. その期間は安定化に焦点があてられる.
- コードが本流に入るまでの安定したフローができた. 今は多くの人々その新しいコードをテストしている.
- 機能の追加はより速やかになった.
- ベンダは現行のリリースで直に作業ができるようになり, 本家ヘの変更は容易になった.
残った問題
- 2.6 カーネルべースの長期安定版がない. Adrian Bunk による 2.6.16 の長期メンテナンス・ツリーはその問題にとりくんでいるが, 影響力の大きさについてはまだわからない.
- バージョンをまたいだ退行が頻繁に起こるようになった. 退行バグの制御や追跡には改善を要する.
- 不具合管理ツールの Bugzilla をもっとうまく開発プロセスに統合し, QA 担当者に役立つものにする必要がある. 2007 年 1 月, Google は Andrew Morton と仕事をする QA 担当を探している旨の発表をした.
OpenOffice?
OpenOffice?.org は複数のアプリケーションを統合して提供するオフィス・スイートだ.
ワード・プロセッサや表計算などがある.
もともと StarDivision? 社によって開発された StarOffice? は Sun に買収された.
2000 年 7 月, Sun はそれを OpenOffice?.org という free software としてリリースした.
OpenOffice? の開発では, 今も Sun が強い権限を維持している.
とはいえ他のベンダ, 特に Novell はプロジェクトの有力な貢献者となっている.
Sun の商用製品である StarOffice? として,
かつてのプロジェクトは 18 ヶ月という長いリリース間隔をかけていた.
遅延は多く, ベンダがどのバージョンを含めるべきか判断するのは難しかった.
長い遅延を経た 2.0 のリリース以降, OpenOffice? は 3 ヶ月のリリース間隔へ移行した.
2.0 のリリースは 1.1 以来 26 ヶ月ぶりのものだった.
新しいリリース間隔は前向きに受け止められた.
貢献者からすれば, 機能や修正がより早くユーザに届くようになる.
そんな中, 2006 年の終わりに議論があり, 6 ヶ月間隔のリリースがもちあがる.
ユーザは 3 ヶ月毎の新機能を望むほどに見えず,
また間隔が短かいことで QA チームに多大な圧力がかかってしまうためだ.
| Version | Date | Months |
| 1.0 | 2002-05-01 | - |
| 1.1 | 2003-09-02 | 16 |
| 2.0 | 2005-10-20 | 26 |
| 2.0.1 | 2005-12-21 | 2 |
| 2.0.2 | 2006-03-08 | 3 |
| 2.0.3 | 2006-06-29 | 4 |
| 2.0.4 | 2006-10-13 | 3 |
| 2.1.0 | 2006-12-12 | 2 |
これまでの問題
- StarOffice? という製品に縛られてリリース間隔が 18 ヶ月と長かったため, テストも長期間ほとんど行なわれなかった. 開発者がリリースをずっと先だと思ってしまったからだ.
- 長い開発フェーズの間に多くの変更が集積し, 最後までテストを持っていくのがとても難しくなってしまった. それが 'ビッグバン' リリースにつながった.
- 機能が終盤に追加された. ベータ期間にすら機能追加があった. 次リリースが 18 ヶ月遅延するという認識のためだ.
- コードレビューがほとんどなかった. QA チームはプログラムをテストするだけだった.
- ベンダはリリース前のバージョンを出荷した. 2.0 の大きな遅延のせいで計画のたてようがなかったためだ.
対策
- 2.0 のリリース以後, プロジェクトは 3 ヶ月周期のリリースに移行した. このモデルならユーザからのフィードバックを細やかに反映できる.
- 速いリリース間隔とベンダ間の協調により, コードレビューが促進された.
- プロジェクトへの動機付けが増した. 自分の貢献が妥当な時間でユーザに届くのを見届けられるようになったためだ.
- リリース・プロセスの透明性が増した. おかげでボランティアの貢献者がリリース準備でもより活発に動けるようにった.
残った問題
- リリース間隔を 6 ヶ月にしようという議論がある. ユーザによっては 3 ヶ月毎の機能追加を必要としないことがわかっている. 3 ヶ月という攻めのリリース間隔は QA チームに大きな負担をかけてしまう.
Plone
Plone は Zope という強力なアプリケーション・サーバを使って作られた
コンテンツ管理システムである.
プロジェクトは 2.1 のリリースに際して大きな遅れをもった.
Plone コンサルタントは古いリリースを使うか新しいのを待つかの選択に苦しんだ.
ようやく 2.1 がリリースされた時も,
多くのユーザはアップグレードに問題を抱え, 多数の変更を迫られた.
これらの問題を解決するため, また Zope のリリースと足並みを揃えたいこともあって,
プロジェクトは 2005 年から 6 ヶ月毎の時間ベースのリリースに移行した.
| Version | Date | Months |
| 1.0 | 2003-02-06 | - |
| 2.0 | 2004-03-23 | 13 |
| 2.1 | 2005-09-06 | 17 |
| 2.5 | 2006-06-16 | 9 |
これまでの問題
- リリースは, 特に 2.1 では実施までに長い時間を要した.
- リリースでの変更が多く, 移行にはいくらかの問題があった.
- 多くの Plone 開発者は Web サイト構築を請け負うコンサルタントだ. Plone が予測不可能であるため, 彼らは将来のプロジェクトにどのバージョンを使うべきか選択に苦しんだ.
対策
- 時間ベースのリリースに移行した. Zope フレームワークがそうだから, という理由もある. おかげで Plone は新しい Zope の機能が使えるようになった.
- 時間ベースのリリースのおかげで, プロジェクトをより構造化できるようになった. たとえば, 新機能は Plone Improvement Proposals (PLIP) として提案することになった. フレームワークのチームはこれをレビューする.
- 締切があるおかげで, ある時間内に機能を作り上げようと開発者が同期づけられるようになった.
- Plone コンサルタントは将来の商用プロジェクトにどのバージョンを採用するか前もって決められるようになった
残った問題
- 時間ベースのリリースに移行して間もないため, プロジェクトはこれからも継続して時間どおりにリリースできることを示す必要がある.
X.org
かつて, 大半の Linux ディストリビューションやその他の free software のプロジェクトは
XFree86 システムに依存していた.
時間が経つにつれ XFree86 プロジェクトの構造は硬直化が進み,
進歩を続けて他の free software コミュニティと歩調を合わせることができなくなってしまった.
2004 年の 2 月に XFree86 がライセンスを変更したとき,
活発なコミュニティや大半のベンダは即座に X.org へ移っていった.
X.org は非常に活発なコミュニティだ.
彼らはモノリシックなコードベースの分割と, よりモダンなビルド・システムへの移行を決めた.
X.org 7.0 からプロジェクトはモジュール化されたシステムとなり,
各コンポーネントは別個に開発, リリースされている.
プロジェトは二段構成のリリース機構を備える開発の仕組みをうまくとりいれた:
まず各コンポーネントは必要に応じてリリースされる. 加えて X.org 全体でのリリースがある.
そのリリースでは各コンポーネントの安定版がまとめられる.
この全体リリースは 6 ヶ月毎に行なわれる.
| Version | Date | Months |
| 7.0 | 2005-12-21 | - |
| 7.1 | 2006-05-22 | 5 |
| 7.2 | 2007-02-15 | 9 |
これまでの問題
- XFree86 は数年に一度しかリリースされなかった. 計画はなく, プロジェクトの構造は硬直していた.
- コードベースは巨大で一枚岩だった. 古臭いビルドシステムを使っており, これに不満のない開発者はほとんどいなかった. このせいで新しい貢献者は参加するのが難しく, テストにも都合が悪かった.
対策
- モノリシックなシステムからモジュール化されたシステムに移行した. テストはやりやすくなったし, 貢献者に対して特定のコンポーネントへの書込み権限を与えることができるようになった.
- モジュール化されたシステムのおかげで, 二段構成の仕組みを使えるようになった. 各コンポーネントは状態に応じてリリース, 全体でのリリースは 6 ヶ月毎に行う.
- 全体リリースには代替のための仕組がある. あるコンポーネントがリリースできる状態になかったら, 前のリリースで代用することができる.
残った問題
- プロジェクトはサーバとドライバのインターフェイスにならなければいけない. そのため, ハードウェア・ドライバの更新はより高い頻度でリリースしたい.
