このページは KernelPractice の翻訳です。
分散開発, Linuxカーネル方式
この方式では数人の中心的な開発者が他人から提供された変更点をチェックし、自分のリポジトリに統合していきます。通常それぞれの開発者がリポジトリを公開します。
個々のサブシステムはそのサブシステムのメンテナが面倒を見ます。そのメンテナがサブシステムの開発をし、サブシステムに関するほかの開発者からの変更を集積します。必要に応じてメンテナは自分のリポジトリを公開し、これでよいと思った時点で中央の開発者に自分の変更点をpullするよう依頼します。
サブシステムのメンテナは雑多なパッチを受けとり、それを吟味し受け取るか捨てるかします。
上流にマージしたい開発者はその上流のリポジトリの最新のリビジョンとの差分を作るようにします。こうすればマージが衝突する可能性を下げることができます。衝突してしまうとその差分が受け入られる可能性が低くなります。
リポジトリの寿命と種類
このモデルにおいて、ほとんどのリポジトリは短命です。典型的に開発者は以下の種類のリポジトリを使います。
- 「正式な」リポジトリのコピー
- これは「クリーンな」コピーであり、上流のソースコードを参照するために使います。
- いくつかの「incoming」ツリー、サブシステムのメンテナによって管理されているリポジトリの最新のコピー
- 「クリーンでない」ツリーであり、外部からの他の開発者の開発の様子を追跡するのに有用です。ここでの変更を
- この種のツリーはcronを使って定期的にpullすると便利でしょう。
- 作業用の短命リポジトリ
- ローカルでの作業のためのサンドボックスのようなものです。どんどんコミットしうまくいかない変更はどんどんアンドゥします。成果物は一つのチェンジセットとして取りだし「outgoing」ツリーに取り込みます(訳注:つまり複数のチェンジセットを1つのチェンジセットにまとめる必要があります)。
- サブシステムのメンテナのツリーにとりこまれていないチェンジセットを含む短命なリポジトリ(これはサブシステムのメンテナに向けた「outgoint」ツリーではないのか？)
- 少数の「outgoing」ツリー
- 違う人に配布するための一連の変更を含んでいます。これは「クリーンな」ツリーであり、この内容が最終的には上流のツリー、もしくは「正式な」リポジトリにとりこまれます。
チェンジセットの衛生状態
リポジトリが「クリーン」であるというのは、各変更が自己完結していて、謝りを作ってしまったチェンジセットを含まないことです。こうすることで更新履歴がミスで乱雑になることを防げます。(訳:ここは文章がわかりにくいのですが、おそらくバグを作りこんでしまったチェンジセットとそれの修正というチェンジセットが分かれていてはならないということでしょう)。
リポジトリが「クリーン」に保つのは少々面倒です。複数の変更をまとめて「クリーン」なパッチを作らなければならないからです。少なくともLinux kernelの場合においてはこれはそれほど重荷になっているわけではないようです。