3月もなかばを過ぎ、そろそろUbuntu 12.04の最終的な形も見え始めてきたところです。今月末にはベータ2のリリースも控えているので、今回はUbuntuのベータ版を使う上でのポイントを紹介します。
ベータ版を使う前に
ベータ版を使うメリット
Ubuntuはリリースされた後の修正・変更に対して、セキュリティ関連を除いて慎重になる傾向があります。実際のところリリースから1ヶ月程度であれば、リリース後に見つかった不具合の対応も活発に行われることになりますが、対応によって新たな不具合が発生することを防ぐために手続きが厳格になること、まずは開発版での修正を確認できない限りはリリース版には反映されないこと、メインの開発者が次期リリースの開発に軸足を移していくことなどから、開発時の修正に比べるとハードルがあがります。
そこで、開発版の段階で一通り確認して問題点を報告しておいたほうが修正されやすいのです。
Ubuntuのリリーススケジュール
Ubuntuは半年の開発期間を1サイクルとしてスケジュールを立てています。例えば12.04の開発スケジュールを確認すると、4月26日のリリース日に向けて、今週の木曜にはベータ2に向けたフリーズ、来週の木曜の29日にはベータ2のリリースが行われることがわかります。その後は、後述する各種フリーズが行われつつ、最終的なリリースに向けた品質の向上が行われるのです。
図1 4月になると品質向上フェーズに入る
なお、Ubuntu Japanese Teamが配布している日本語Remixは、本家のリリース後にそのアーカイブデータを元に生成・テストを行うため、リリースまでにさらに日数を要します。
ここ数回の開発サイクルの傾向として、アルファ期間中は各チームの基本的な開発が進み、ベータ1リリース後にその成果物がどんどん取り込まれ、ベータ2あたりである程度完成形としてまとまった上で、リリースに向けてブラッシュアップを行うという形になっています[1]。
アルファやベータ1は、毎日のように3桁近くの大量アップデートがあり、予期せぬトラブルに遭遇して頭抱えながら復旧するというサプライズイベントも用意されているため、Ubuntuそのものの開発に携わっている人にとっては、触っているといろんな変化が目に見えて現れて楽しい状態です。
ただそれだけにころころ環境が変わることに対する適応力と広い心が求められます。これがベータ2ぐらいになると、ある程度落ち着いてくるので、じっくりと状況を確認することができます[2]。
フリーズとは
「フリーズ」は一つの開発サイクルにおいて、各自が勝手に機能追加や削除、修正を行うことで、成果物がしっちゃかめっちゃになってしまわないようにするための、開発者間の決めごとです。例えば以下のようなフリーズが存在します（注3。なお、各フリーズの名称の後にある括弧内の日付は12.04の場合です）。
- Feature Freeze（2月16日）
新機能やAPIの導入に対するフリーズで、2月16日に行われました。この日以降、例えばパッケージのバージョンをあげるときのように新機能の導入が発生するケースにおいては、Feature Freeze Exception（FFe）という手続きを経る必要があります。実際のところこのフリーズ以降も大なり小なり新機能の導入は行われますので、あくまで目安的な位置づけです。
- User Interface Freeze（2月23日）
これ以降、標準でインストールされるソフトウェアのユーザーインターフェースは、変更されないことが期待されます。また、変更する場合はドキュメントチームや翻訳チームへの報告が必要です（UIFe）。これは、インターフェースの変更にあわせて、ヘルプドキュメントの作成や翻訳も追随する必要があるためです。
- Documentation String Freeze（3月22日）
このフリーズによって、ヘルプドキュメントの原文が確定します。これにより翻訳チームは大きな変更の心配をする必要なくヘルプの翻訳に注力できます。
- Kernel Freeze（4月5日）
各種ビルドプロセスに使われるカーネルは、他よりも少し早いタイミングで最終的なフリーズが行われます。
- Final Freeze（4月12日）
リリースの2週間前になると、CDイメージの品質向上に努めるため、よほど致命的な不具合でない限りはリリース日まで各ソフトウェアのアップデートが停止されます。ただし、翻訳自体は引き続き行えます。
先述したように「フリーズ」はあくまで「目安」であり、フリーズが行われたあとも適切な「例外手続き」を踏めばアップデート可能です。特に今回は5年間のサポートを行うLTSリリースでもあるため、積極的に開発に関わり、FFeやUIFeを行って品質を改善していくことが期待されています。
とはいえいきなり「例外手続き」に手を付けるのはハードルが高いため、Ubuntuの開発にはじめて参加する場合は、上記の目安にしたがってその時その時で「求められていること」を見つけるのが良いでしょう。
ベータ版の使用上の注意
ベータ版はあくまで開発途中のバージョンであり、アップデートするといきなり起動しなくなって、場合によっては再インストールしなくてはならない自体になる可能性もないとは言えません。
予備のマシンや仮想環境にインストールする、いきなり起動しなくなったときにもすぐに元に戻せる状態にしておくなどの自衛策を講じておいてください。
特にVirtualBoxなどの仮想マシンは、アップグレード前のスナップショットに差し戻したり、問題が起きる環境を複製して再現性をチェックしたりといった操作を簡単に行えるため開発版を使用する環境としてもおすすめです。
致命的な不具合に関するアナウンスやテスト要請などは、ubuntu-devel-announceメーリングリストに流れますので、こちらを登録しておきましょう。
ベータ版のインストールとアップグレード
ベータ版を使う場合、まず最初に確認すべきは「インストールできるかどうか」もしくは「一つ前のリリースからアップグレードできるかどうか」です。特に後者については、テストする人が不足していることもあって、より多くの人によるチェックが期待されています。
クリーンインストールする場合は、ベータ2配布開始の公式アナウンスを待って、配布元からCDイメージをダウンロードし、リリース版のインストールと同様にインストールを行います。
11.10からアップグレードする場合は、Alt+F2を押して「update-manager -d」と入力します（図2）。アップデートマネージャーが起動しますので、あとは12.04にアップグレードするための指示にしたがってください。
図2 「アップグレード」ボタンを押すと、12.04へのアップグレードが開始される
10.04からアップグレードする手順は、こちらで公開されています。ただし、ベータ1の時点では問題があり、アップグレードできないことに注意してください。この問題は先日解決しましたので、ベータ2のリリース時にはテストできるようになっているでしょう。
なお、インストールする場合もアップグレードする場合も、リリース版と同じように必ずリリースノートを確認してください（ベータ1のリリースノートの例）。
ベータ版で確認したいこと
べータ版をテストして不具合を見つけた場合、大雑把に以下のようなステップを踏んで報告するようにしてください[4]。
- 不具合を見つける
- 再現方法を確認する
- アップデートマネージャで最新版にアップデートしても再現するか確認する
- 過去のリリースやバージョンで同じ問題が発生するか確認する
- 問題が発生しているパッケージを特定する
- 既に同様の報告があがっていないか確認する
- 不具合を報告する
さらに追加の手順として、他のディストリビューションで確認したり、回避策を見つけたり、不具合を修正するパッチを作成したり、パッチを適用したパッケージを作成したりするのですが、そこまでできる人であれば、たぶん詳しい説明をする必要はないでしょう。
不具合を報告する場合は、最低でも1から3と6、7は抑えておきたいところです。特に2については、より詳細でシンプルな再現手順を見つけられればそれだけ解決に近づくことになるので重要です。
4は情報として提供すると、開発者が問題を特定しやすくなります。開発期間中であれば「xx日にはこういう動作をしていたけれども、oo日からはこういう動作になった」という具体的な違いについて説明できると良いでしょう。
5は若干難易度が高いですが、一度方法を覚えてしまえばそれほど複雑ではありません。例えば、Ubuntu標準のアプリケーションで問題が発生するのであれば、ヘルプ＞問題点を報告するをクリックします。すると問題報告に必要な情報が収集され、最終的に図3のようなダイアログが開きますので、「Package」の部分を見ればパッケージ名を特定できます。このときSendを押すとブラウザでLaunchpadの投稿画面が開きますので、必要な情報が揃っているならそのまま報告しても良いでしょう。
図3 Packageのところにパッケージ名とバージョン番号が表示される
もし、「問題点を報告する」がないアプリケーションの場合は、Alt+F2を押して"ubuntu-bug -w"と入力し、ダイアログに従って問題となるアプリケーションのウィンドウをクリックすることで同様の確認が行えます。
「問題を報告する（ubuntu-bugコマンド）」を使えば、6のような報告済みかどうかの確認も行ってくれます。手動で行う場合は、エラーメッセージやパッケージ名を元にGoogleで以下のように検索する手もあります。
error message package site:bugs.launchpad.net
必要な情報が揃ったら最後は報告です。パッケージ名がわかっている場合は、Alt+F2や端末から以下のコマンドを入力するだけです。
ubuntu-bug パッケージ名
必要な情報が収集され、Launchpadが開きますのでそこに再現手順（procedure）、本来期待される挙動（expected result）、実際に発生した挙動（actual result）などを記述してください。
どうしてもパッケージ名がわからない場合は、Ubuntu自身に対して不具合報告をすることも可能ですが、開発者が不具合を見つけ辛くなりますのでできるだけ避けてください。そのようなときはまず、フォーラムやメーリングリストでパッケージ名について相談してみましょう。
報告時にLaunchpadが類似の報告をリストアップしてくれます。リストアップされたものについては一通り目を通し、同じ内容のものがないか確認してください。もし同じ内容の不具合が存在するのであれば、新規投稿はせずに、既存の投稿のタイトル右下にある炎のアイコン（bug-heat）をクリックして自分にも影響があることを示し、必要であれば追加の情報を投稿します。
インストール時のテスト
インストールのテストはなるべく多種多様な環境で行う必要があります。特にリリース直前は、QAサイトにてインストールイメージのテスト要請が行われるので、ぜひ参加するようにしてください。
今回の12.04はLTSリリースであり、「11.10から12.04 LTSへのアップグレード」のテストだけでなく、「10.04 LTSから12.04 LTSへのアップグレード」も対応しているため、そちらのテストも必要になります。
アップグレード時に問題が出る場合は、ベータ版ではなく毎日更新されているdaily-liveイメージでも試してみてください。ひょっとするとこちらで修正されているかもしれません（それでも問題が出る場合は、ubiquityに対してバグ報告を行ってください。
ハードウェアサポート
インストールが完了したら次はハードウェアのテストを行うと良いでしょう。ハードウェアサポートの大半はLinuxカーネルが担っているので、できればカーネルフリーズよりは前に解決しておきたいところです。
具体的には以下のような項目をテストします。
- マウスとキーボード、タッチパッド
- 有線LANや無線LANなどのネットワーク
- ディスプレイの出力
- サウンド出力や音量調整、ヘッドフォン、マイク
- サスペンド・ハイバネート・シャットダウンなどの電源管理
- ノートPCなら、画面輝度の変更ができるかどうかやACアダプターの抜き差しを検知できるかどうか
- Bluetooth
- プリンター・スキャナー・USBドングルなどの外部周辺機器
システムテストツール（checkbox）を使えば一通りのテストが行える上に、動作状況をLaunchpadに報告できるので、まずはこれを使ってみてください（図4）。
図4 全部やるとかなりの量になるものの、ハードウェアテストを一通りできる
不具合は、ハードウェアが認識されないならカーネルへ、認識されるものの設定がうまくいかないならその設定ツールへ報告します。
アプリケーションとインターフェース
Ubuntuの開発版では数多くのアプリケーションのバージョンがあがっています。特にUnityやGNOMEといった基本的なインターフェース、FirefoxやLibreOfficeなどのメジャーアプリケーションのインターフェースの更新は使い勝手を向上させるとともに、過去に設定できていた項目の場所が移動していたり、場合によってはなくなっているということも発生し得ます。
そこで、普段よく使うアプリケーションは一通り起動し、使用方法や設定方法が変わっていないか、もしくはどういう風に変わっているかを確認しておきましょう。設定項目がなくなっている場合は、別の手順が用意されている可能性もありますので、アプリケーションの変更履歴（大抵の場合は、/usr/share/doc/パッケージ名のディレクトリに存在します）を読むと良いでしょう。
今回Unityは、HUDという新しいインターフェースを用意しています。現時点では既存のインターフェースを置き換える類のものではありませんが、操作に慣れると便利なケースもありますので、どんどんトライして自分なりの利便性を見つけてみてはいかがでしょうか。
ソフトウェアセンターからインストールできるアプリケーションが万が一起動できない場合、それは深刻なバグであると判断されますので、リリーススケジュールに関係なく不具合報告をしてください。
日本語入力環境
日本語の入力を正しく行えるかどうかの確認は、英語圏の人にとっては難しい作業です。このためどうしても不具合の発見や対応が遅れがちになります。ただ、確認が難しいだけであって、決して「対応しない」わけではありません。そのため、日本語入力を含む各国語の入力関係のネイティブによる報告は常に歓迎されます。
普段使うアプリケーションで日本語入力できるかどうかを確認し、もし問題あるようであれば積極的に報告すると良いでしょう。
例えば、以下のような環境はうまくいかないという報告をよく受けるので、入念にテストしていただけると助かります。
- ブラウザ上のFlash
- Javaアプリケーション
- UnityのDashやHUD
図5 Altボタンを押して表示さられるHUDでも日本語を入力できる必要がある
日本語入力の場合、大抵はibusパッケージに対して不具合報告すると良いでしょう。
翻訳とドキュメント整備
ベータ版を使っていると未翻訳な部分がたくさん見つかるはずです。翻訳はできるだけリリース直前まで行われたものを取り込むようなスケジュールになっているため、ベータ2あたりから活発化していきます。
Ubuntuでは原則として、「mainリポジトリに入っているアプリケーション」については、Launchpad上で翻訳し、LanguagePackとして提供することになっています。それに対して「universeリポジトリに入っているアプリケーション」はLaunchpad上では翻訳できませんので、アプリケーションの開発元で翻訳することになります[5]。ユーザーインターフェースだけでなくヘルプドキュメント類も同様にLaunchpad上で翻訳可能です。
スケジュールに戻ると、訳語がLanguagePackに取り込まれる期限がリリース10日前のLanguagePackTranslationDeadlineです。また、インストールCDで使われる訳語については、それよりさらに1週間前のNonLanguagePackTranslationDeadlineが期限になるので注意してください。
これらの期限を越えても翻訳は可能ですが、反映されるのはリリース後にLanguagePackアップデートが行われるタイミングか、LTSの場合はマイルストーンリリースが行われるタイミングになります。
Japanese Teamでは翻訳に際して、いくつかのルールを設けています。翻訳を行う前に、こちらのメーリングリストの投稿にある情報に目をとおしてください。
特に翻訳に対して「翻訳する人とそれを査読する人は分ける」というルールが重要になります。せっかく翻訳していただいても、このルールが守られていない場合、翻訳を破棄しなくてはいけなくなる場合もありますので、特に注意してください[6]。
ちなみにリリースノートに関してはWikiベースで翻訳されます。こちらはほぼリリース日に行われるため、リリース日に時間のある方は、一緒に参加し、チェックを行ってもらえると大変助かります。
日本語Remix関連
Japanese Teamは、いくつかのパッケージを日本語Remix用にPPAで公開しています。主に本家の方でなんらかの理由で修正が取り込まれなかったものや、時間的に間に合わなかったものなどを提供しています。
FinalFreeze後であっても、日本語環境を改善する十分な理由がある修正であれば、日本語Remix向けに修正することもありますので、問題点に気づいた場合は、こちらのWikiページにリストアップしてください。
まとめ
リースまで1ヶ月近くになったとはいえ、まだまだ修正すべき点がたくさんあります。さらに今回はデスクトップも5年サポートされますので、ぜひ今のうちにテストを行い、気になる点を積極的に報告するようよろしくお願いいたします。
