平行して行われるリリースを同時に管理するということから、 日々の開発のやり方を推測することができます。 特に、次のことはどんなときでも推奨される強制的な規律になります。 つまり、コミットのひとつひとつは、論理的な変更単位であること、 そして関連のない変更をごっちゃにして一度にコミットしてはいけない、ということです。 変更する量がとても多い、または一度にコミットするのが破壊的である場合は、 それをN回のコミットに分割し、 それぞれのコミットが変更全体をうまく分割したサブセットであるようにします。 そして変更全体に関係のないものは一切含まれないようにします。
次に示すのは、まとまりのない悪いコミットの例です。:
------------------------------------------------------------------------ r6228 | jrandom | 2004-06-30 22:13:07 -0500 (Wed, 30 Jun 2004) | 8 lines 問題 #1729 を修正 : インデックス作成を上品に行うようにした。これに伴い、 ファイルにインデックスを作成している最中にユーザーがファイルを変更していたら警告するようにした。 * ui/repl.py (ChangingFile): 新しい例外クラス (DoIndex): 新しい例外を処理するようにした * indexer/index.py (FollowStream): インデックスを作成中にファイルが変更されたら、例外を生成するようにした (BuildDir): 上記とは関係ないが、いくつかの古いコメントを削除し、 コードのフォーマットをいくつか修正した。また、ディレクトリ作成時のエラーチェックを修正した。 その他関連のないクリーンアップ: * www/index.html: typoを修正し、次のリリース日を設定。 ------------------------------------------------------------------------
問題点が浮き彫りになるのは、来るべきメンテナンスリリースに備えて、
BuildDir
関数のエラーチェックをリリースブランチに移植する必要が出てきたときです。
移植する人は、それ以外の変更点はいらないのです。
たとえば、問題 #1729 の修正自体をメンテナンスブランチに取り込むことは認められず、
index.html
の調整もここでは関係ありません。
しかし、BuildDir
の変更を、
バージョン管理システムのマージ機能を使って容易に取り出すことはできません。
なぜなら、バージョン管理システムは、
この変更を他の関係のないものとグループ化するように指示されているからです。
実際には、マージする前でさえ問題が出てくるでしょう。投票を行うために変更点を羅列する場合です。:
投票を提案する人は、該当する変更のリビジョン番号を与える代わりに、
提案されているコミットの一部分を分離するためだけに、特別なパッチを作ったり、
変更用のブランチを切らなければならなくなります。
このため、他の人がうんざりする量の仕事をすることになります。
それというのもすべて、変更点を論理的なグループに分割するのを面倒臭がったコミッターのせいなのです。
実際には、このコミットは 4つ に分割すべきでした。
ひとつは 問題 #1729 の修正、
もうひとつは 古いコメントの削除と BuildDir
関数のコードフォーマットの修正、
そして BuildDir
関数のエラーチェックの修正、
最後に index.html
の微調整です。
3番目のコミットこそが、メンテナンスリリースのブランチに含めるよう提案されているものなのです。
それぞれのコミットを論理的な変更単位に分割するのが望ましいのは、 もちろんリリースブランチを安定させるためだけではありません。 心理的にも、意味がまとまっているコミットはレビューしやすく、 必要な時に元に戻しやすい (バージョン管理システムによっては、変更を元に戻すことで、特殊なマージを行うものもあります) ということもあります。 前もって皆が規律をちょっと守っておけば、プロジェクトが後に頭痛の種を多く抱えずに済むのです。
オープンソースプロジェクトが、歴史的に独占的なソフトウェアのプロジェクトと異なる点は、 リリースの計画に関するものです。 独占的なソフトウェアのプロジェクトでは、確固とした〆切があるのが普通です。 その理由は、顧客にある時点でアップグレードを提供すると約束している場合もあれば、 新しいリリースをマーケティング上の理由から他の仕事と連携させる必要があったりとか、 プロジェクトにお金を出しているベンチャーキャピタルの人が、 さらに投資をする前に成果を見る必要がある場合もあります。 一方、フリーソフトウェアプロジェクトでは、 ほとんど文字通りの意味での「道楽」が最近までほとんどの動機付けとなってきました。: つまり、好きだからコードを書いてきたのです。 全ての機能が揃う前にリリースする必要性を感じる人はいませんし、 そもそもなぜそうすべきなのでしょう? フリーソフトウェアプロジェクトでは、皆の仕事がひとつの生産ラインに乗っているわけではないのです。
最近では、多くのオープンソースプロジェクトが企業からお金を出してもらうようになり、 それに伴って企業の〆切文化の影響をより多く受けるようになってきています。 これは多くの点では良いことなのですが、 お金を貰って雇われている開発者とボランティアの開発者の間で、 優先順位の衝突が起きる可能性があります。 こうした衝突はリリーススケジュールをいつ、どのようにするかという問題でよく発生します。 プレッシャーが強い雇われ開発者は、当然リリースする日程を決めたがりますが、 ボランティアの開発者は他の問題意識の方が強いかもしれません — それは自分たちが求める機能や、仕上げておきたいテストであったりします — よって、ボランティアの開発者達はリリースを待つべきだと感じることになります。
もちろんこの問題については、議論し、妥協する以外に一般的な解決策はありません。 しかし、提案されているリリースの 存在 から、 日付を切り離すことで、衝突の頻度や度合いを最小限にすることができます。 つまり、はじめはざっくりとした見積り[29] 以外は日付について触れず、 直近から中期的な段階で、プロジェクトはどういった形のリリースができるか、 そしてそのリリースにどんな機能を含めるのか、という方向に議論を誘導してみるのです。 機能について早期に確定しておくことで、 個々のリリースに関する議論が複雑になる度合いを減らすことができ、 予測可能性を高めることができます。 また、新機能や他の複雑なことをリリースに追加することで、 リリースの定義を拡大解釈する提案に反対させるある種の先入観を植え付けることができます。 たとえリリースの日取りが決まっていなくても、 その内容がうまく決まっていれば、 リリースの内容を拡大するのを正当化するのはそれを提案する人の責任になります。
トマス・ジェファーソン の伝記 Jefferson and His Time では、 Dumas Malone が、バージニア大学の組織を決めるための初ミーティングを彼がどのように進めたかについて語っています。 大学を設立するというアイディアはもともとジェファーソンのアイディアでしたが、 (オープンソースプロジェクトに限らず、どこででもあることですが) 他の多くの関係者が、自分たちの興味があることや議題を持って会議に乗り込んできたのです。 彼らがミーティングに集まってそれらを徹底的に議論していると、 ジェファーソンは周到に準備した建築図面や、その予算や実作業、提案されているカリキュラム、 そして自分がヨーロッパから輸入したいと考えていた特別な学部の名前を示して見せたのです。 会議室にいた人の中に、彼以外でそうした議題についてほんのわずかでも準備にした人はいませんでした。 つまり、彼らはそうした議題についてはジェファーソンのビジョンに従わざるを得ません。結局、 バージニア大学設立は多かれ少なかれ彼の計画通りに進んだのです。 建築費が予算をオーバーしていたり、彼のアイディアの多くは様々な理由で実現しなかったりしましたが、 ジェファーソンはそれらすべてが起こることをあらかじめ完全に予想していたのでしょう。 彼の狙いは戦略的でした。ミーティングで他の人が修正を提案せざるをえないような現実的な路線を提示するようにしたのです。 その結果、全体の枠組み、そしてプロジェクトのスケジュールも、だいたい彼が望むものになったのです。
フリーソフトウェアプロジェクトの場合、"ミーティング" はありませんが、 小さな提案の積み重ねは、そのほとんどがバグ追跡システムで行われます。 プロジェクトであなたがちょっと信頼されていて、 いろいろな新機能や改善やバグ修正をターゲットとなるリリースに割り当てはじめれば、 アナウンスした全体のプランに従って、人々はあなたについてくるでしょう。 いったんそれらが多かれ少なかれあなたの思い通りに進めば、 実際のリリース 時期 に関する議論もより進みやすくなるでしょう。
もちろん、個々の決定をまるで文書で確定したかのように示さないのが重要です。 特定のリリースで問題の解決をすると決めるときには、 コメントで議論に参加してもらい、反対意見を述べてもらったりし、 可能な時はいつでも、真摯に説得に応じましょう。 単に権力を行使するために、力を振りかざしてはいけません。 リリース計画を立てる過程で他の人が議論に参加すればするほど (8章ボランティアの管理 の 「技術的な作業だけでなく管理作業もみんなで」 を参照してください) 、 自分が本当に重視している問題の優先度を高めることに賛同するよう説得することも容易になるのです。
リリース計画を立てるときに緊張を緩める別の方法として、 リリースを頻繁に行うことがあります。リリースする間隔が長期間空くと、 それぞれのリリースの重要性がメンバーの中で増してしまいます。 つまり、自分たちのコードが取り込まれなかったときのショックが大きくなってしまうのです。 なぜなら、次に取り込まれるチャンスまでどれくらい時間がかかるかがわかってしまうからです。 リリースプロセスの複雑さと、プロジェクトの性質にもよりますが、 3ヶ月から6ヶ月の間くらいが、普通は適切なリリース間隔です。しかし、 安定版のリリースラインは、もうすこし早い間隔でマイクロリリースを出した方がよいかもしれません。
[29] 別のアプローチとして、 Martin Michlmayr の Ph.D論文 Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management (http://www.cyrius.com/publications/michlmayr-phd.html) を読むとよいかもしれません。 これは巨大なソフトウェアプロジェクトにおいて、 機能ベースのリリースプロセスとは正反対の、 時間軸をベースとしたリリースプロセスを採用することに関する論文です。 Michlmayr は、Google でこれを題材にした講演も行っています。Google Video で視聴可能です。http://video.google.com/videoplay?docid=-5503858974016723264