先週、CentOS 6 はいつ頃出るのかどうか、ふと気になりました。
リリース予定もニュースにならないし、どうしたのだろうと調べていたら、CentOSの開発MLが荒れていることを知りました。
不安を感じた私は調査を続けました。
すると、LWN.net の一つの記事に、CentOS の開発の現状について書かれたものがあることを発見しました。
それを読んでまず知ったのが、CentOS は単純に RHEL のソースをリビルドするだけではなく、かなりの労力を費やして作られるディストリビューションであるということです。
そして、開発コミュニティの運営に苦戦している CentOS 開発チームの姿がそこにはありました。
この記事は是非多くの人に読んでもらいたいと思い、何人かの人にレビューをお願いした上で翻訳してみました。
それでは本編をどうぞ。
CentOS 6 の困難、立ち向かう人々
| Original Title | CentOS grapples with its development process |
| Author | Nathan Willis |
| Japanese Translator | Sho Shimauchi (@shiumachi) |
| Translation Reviewer | nhoriguchi (@nhoriguchi) |
| Shintaro Shirai (@berutarube) | |
| Tomoyuki Okubo | |
| Hiroki Ishikawa (@ishikawa84g) | |
| Original URL | http://lwn.net/Articles/417849/ |
2010年12月1日
CentOS(コミュニティエンタープライズオペレーティングシステム community enterprise operating system) という Red Hat Enterprise Linux (RHEL) をソースパッケージからリビルドした OS は、最近次のリリースにあたる CentOS 6 の開発を始めた。しかしながら、パッケージリポジトリ構成やインストール用の提供物の再構築に関する開発チームの議論と、全ての重要パッケージのレビューやテストフェーズに新規ユーザを呼び込むことの困難ついての白熱した議論もあり、開発プロセスの序盤は順調ではなかった。
CentOS はコミュニティが開発したディストリビューションであるのだが、「RHEL とソースレベルで明確に互換性のある派生物」であるが故に例えば Fedora や Debian とは大きく異なる QA*1 とリリースプロセスを取っている。Red Hat は GPL 遵守の一環として、それぞれの RHEL リリースに対してソース RPM を提供している。CentOS ボランティアは新しいリリースが落ちてくると、手分けして全てのパッケージに Red Hat の商標が含まれていない事をじっくりと調べる。CentOSが提供するパッケージから Red Hat の商標を取り除くか置き換えなくてはならないからだ。
これにはロゴ画像や文字列によるブランディング、加えてその他ユーザを「Red Hat と関係がある、あるいは Red Hat 製である」と思わせるようなものはなんでも含まれる。例えばアートワークパッケージなど、着手すべき明らかなものもいくつかあるが、メニューから RPM の spec ファイルに含まれる %description 行に至るまで全て除去・置換されなければならない。この修正は単純な検索置換だけで済むとは限らず、さらに自動バグレポートツール(ABRT)のような Red Hat Bugzilla に関数レベルでリンクしているものもパッチを当てなければならない。このプロセスを完了して初めて、開発チームは 最終的に DL 可能となる ISO インストールイメージに含まれるビルドとパッケージング QA の段階へと移る。
新しい upstream ソース
RHEL 6 のソースは、11/10 にリリースされた。これはその前のメジャーバージョンであるRHEL 5 から 3 年以上経っての事である。base ディストリビューションのサイズは大幅に増加し、現在は DVD サイズの ISO イメージ 2 枚に及んでいる。さらに、RHEL 6 は 4 つのバージョンをリリースしている。サーバ "Server"、ワークステーション "Workstation"、ハイパフォーマンスコンピューティング (HPC) コンピュートノード "ComputeNode"、そしてデスクトップクライアント "Client" である。RHEL 5 のときは 2 つだった(デスクトップ "Client" と サーバ "Server")。
この変更によって CentOS 開発者達は、管理者が数 GB のフルイメージをインストールすることなく機能的な最小サーバをセットアップできる「軽量な」インストールイメージと同じように、サーバやワークステーション版を分割する可能性を含めて再検証しなければならなくなった。過去には、一部の開発者はメーリングリスト上で一つのインストールプロファイルを異なるイメージに分け、RHEL の提供物との互換性をより重視したメンテナンス方法に関心を寄せていると表明したこともあったが、CentOS としては単一 ISO イメージにまとめるアプローチを続けていた。
現在、ワークステーションとサーバを単一プロファイルのままにし続けることでコンセンサスが取れているようだが、RHEL 全体のサイズによってはパッケージを "core" と "extra" DVD に分けざるを得なくなるかもしれない。最小インストールオプションはまだ議論中だが、おそらくそうなりそうである。ゴールはサイズを CD に入る程小さくして USB メディアや仮想マシンで利用したりネットワークに繋がれていない環境でもデプロイしたりできるイメージを提供することである。
いまだに解決していないのはパッケージの再構築問題である。CentOS は Red Hat のサブスクリプションベースの Red Hat Network 更新サービスを、ユーザに更新パッケージを提供するための yum リポジトリに置き換えている。CentOS はそれぞれのリリースに 7 年間の更新をサポートするので、リポジトリを適切に再構成することは重大な決定である。議論の要点はパッケージを "os" と "updates" リポジトリだけに分けるかどうか、あるいは一部の主要でないパッケージを "optional" と "optional-updates" リポジトリに分けるかどうかであるが、これらはインストールメディアを 2 つの DVD に分ける方法に酷似したものになるだろう。
Round 1 と新しいコントリビュータ
さらに異論が多かったのは「Round 1」パッケージ監査プロセスという第2 QA プロセスに関する活発な論戦だった。またそれは、開発に関わろうとする新規ユーザにとって高い参入障壁だと皆の目に映った。RHEL 6 がリリースされた直後の 11/11 に 主要開発者の Karanbir Singh が CentOS 開発メーリングリストに "step one" というタイトルで、助けを呼びかける投稿を行なった。そこで彼は興味のある人達に商標監査プロセスに参加してほしいと呼びかけた。
2週間以上経っても、事態はほとんど進展しなかった。これは今まで RHEL ソースコードが落ちてきてから 6-8 週間以内にリリースしてきた CentOS にとって特に厄介な問題である。多くの CentOS ユーザは Red Hat の RHEL 30 日無償トライアルをテストすることから始めるので、ソース互換性のある CentOS アップデートの数週間の遅れはそれらのユーザをとても不安にさせるのだ。
Singh と他のパッケージャーの激しい言い争い(控えめに言っても脱線)に苛立った開発者の Florian La Roche は、Singh が開発プロセスを十分オープンにしていないからだと非難した。Singh は再びメーリングリストに書いて、「なんか思い込みの強い人がいるようだな」と不満を述べた。つまり、彼は進んで取り組んでくれと頼んだのにほとんど誰もやってくれないから、結果として「いつものメンツ」がやることになり、それは理想のペースより遅いんだ、と不満を漏らしたのだ。
多くの人々がオープンソースの仕事とはそれをしたい人のやり方でやる、だからあなたは何をしてほしいか彼らに言うことはできないと主張するだろう、そして彼らは彼らのしたいときにしたいことをする。多くの人が想像する「したいこと」とはオープンソースの流儀で「楽しい」もののことである。幸か不幸か我々はそうした贅沢ができる(できない)。パイプから出てくるものは対処する必要がある。それは時には我々がやりたいと思うものだったり、目の前にあるからやらなければならないものだったりする。
メーリングリストの議論を解決するのはいつも扱いにくいものだが、この件はいくつかの要因が重なって関係者全員をいらだたせているようだ。第一に、Singh はボランティア達に進んで取り組むように頼んだが、だれも進んで取り組もうとしなかったと認識していることである。第二に、新規ユーザはどうやって取り組むのか、Singh が有意義な指示を提供しなかったと認識していることである。具体的に言うと、Singh はメーリングリストに作りかけの wiki ページを示し、監査プロセスのいくつかの重要なステップをドキュメント化しないままにしているのだ。例えば、幾つかの情報源となる URL は "coming soon" と書いてはあったが、空のまま。wiki やメーリングリストの投稿には監査/未監査パッケージ一覧がどこにあるのか、バグトラッカーに投稿するときはどんなフォーマットにすればいいのか、といったことも書いていない。
第三に、何人かの読者が Singh が議論において彼らの質問の要点への反応ではなく他の投稿者の文法や言葉の選択をこき下ろすので「細かいことにうるさい」と責め立てたことである。第四に、監査と QA プロセスが技術的に機能していたとしても、部外者である新規ユーザからすれば非常に不透明であり、彼らがその状況に苦しみを感じていたことである。Douglas McClendon は 適切に整形されたバグレポートの文書例が不足していること、作業の現在状況を追跡する全体の「プログレスバー」がないことを指摘した。
幸運にも、ようやく全員の頭は冷えてきて、新たにコントリビュータになろうとしている人達は彼らの必要としている文書形式の、より掘り下げた説明を投稿した。Singh もまた要望に応え、参加方法と必要な書式を明らかにし、また「建設的だ……我々は 2 週間前にこうした議論をすべきだったのだ」とも発言した。Round 1 において商標問題をチェックしたかどうかをトラックできる AuditStatus ページもできた。*2
ボランティア不足はもちろん CentOS に限った話ではないのだが、このディストリビューションの性質上、エンドユーザの中からマンパワーを持ってくるのはさらに大変である。デスクトップ用途のディストリビューションと違って、クライアントのためにシステムを展開する請負業者が CentOS ユーザーの多数を占める。彼らは確かに知識の塊であり、メーリングリストで活動する傾向にある。しかしインストールベースで見た時のもう一つの勢力は、RHEL や他のエンタープライズサーバディストリビューションの手堅い代替手段として環境を提供しているような商用 Web ホスティングサービス事業者である。残念なことに、多くのホスティングプロバイダは開発プロセスに参加していないようである。もし参加するのなら、パッケージ監査とテストだけでも、かなりの貢献を生み出すことだろう。
コミュニティ
全てのオープンソースプロジェクトはある種のこうした「開発プロセスの改善」問題に苦戦している。Singhにしてみれば、新たな開発者には過去の CentOS リリースのバグレポートを見て、どうやればいいか事前に準備してこないものもいるように見える。一方、より好ましい書式があると Singh がいうのなら、その書式を示すべきだったのは明らかだ。
同様に、wiki のドキュメンテーションとメーリングリストでの議論の間の隔たりは混乱を助長する一因になっている。Singh が送った最初のボランティア募集メールでは、wiki 上に存在しない「http://bugs.centos.org」について触れていた。彼にしてみれば、彼はそこに最新の情報を提供しようとししていたのだが、新しい開発者にとっては、更新されないままの wiki にリンクを貼った Singh の意図が全く分からなかった。
いい文書を書くことは決して易しくないのだが、オープンソースプロジェクトはもっぱら「ドキュメンテーション」を エンドユーザーマニュアルやチュートリアルという観点で考えすぎである。CentOS の例からも分かるように、開発プロセスのドキュメンテーションがプロジェクトの死活問題までも左右する。たった一年ちょっと前に CentOS がリーダーシップの危機に直面したことを考慮すると、ベテランのコントリビュータのリーダー無しに「よりよい作業方法」を得ること、またそれを一般に入手可能なリソースにすることは、今までいたコントリビュータが居なくなってしまった時のためだけではなく、単に次のレベルへのステップアップの求めに応えようと関心を持つユーザを開発に引き込むために、取り組む必要のあることである。
著作権表示
Copyright 2010 Nathan Willis. All Rights Reserved.
