Drupal 7 開発サイクルで学んだ数々の教訓を生かすこと。そして、Drupal 7 に対するバグ フィックスの速度を上げること。この両方に沿った努力が続けられている。そのなかで、コード ベースの安定性を確保しやすくするために新しい方針が導入された。それはコア コントリビューター チームの主なメンバーたちの勧めに基づくものだが、そのメンバーのなかでも特に際立っていたのが“catch”ことナサニエル キャッチポール (Nathaniel catch
Catchpole) だった。
シカゴの DrupalCon における基調講演で、僕は、重大 (critical) なバグを最大でも 15 に抑えるという「上限値 (cap) 」を新しく取り入れた。重大なバグが 15 を超えた場合、 (いずれかが修正されて) 総数が 15 以下に減るまでは新しい機能やクリーンアップ用のパッチはコミットしない、というものだ。これによって、「他のパッチ群が『フードの下で』 (外見上の動作は変わらないように) 大幅なリファクタリングを実行中なのでコード ベースの『追跡』を行わなくてはならない」という状況に至ることなく、深刻なバグを特定したりそれに対処したりできると考えたのだ。
しかし、この方針も十分ではないことがはっきりした。Drupal 7 では、リリースまでに重大なバグをゼロにするべく「果敢」ともいえる努力が続けられた。しかし、それでも Drupal 7 はリリース時に数百の「重要な (major) 」バグを抱えていた。この状況はリリースのあと劇的に改善されたが、この数字を低く抑えることは大事だ。Drupal 8 がリリースされたとき、安定していてすぐに (問題なく) 使えるようにするためにも。また、バグを修正したり機能を取り入れたりしたとき、 (本来なら) 必要であるにもかかわらず、基になっている数々のシステムをリファクタリングしないことがある。それは僕たちにとって「技術的な意味での“借金” (technical debt) 」をためることになる。この技術的な借金があると、コード ベースはさらに複雑で理解しにくくなってしまう。また、Drupal に取り組んでみようという新しい開発者にとっても道は険しくなる。
(以上の理由で、これから) 作業を進めていくに際して、新しい機能および他の主要なリファクタリングのパッチは、以下の条件が当てはまる場合にのみ Drupal 8 にコミットされるものとする。
- 重大なバグ (D7 のバグと D8 のバグの合計) : 15 以下
- 重要なバグ (D7 のバグと D8 のバグの合計) : 100 以下
- 重大なタスク (D7 のタスクと D8 のタスクの合計) : 15 以下
- 重要なタスク (D7 のタスクと D8 のタスクの合計) : 100 以下
詳細についてはDrupal コア コード フリーズ、コード解凍、案件リストの基準値 (Drupal core code freeze, code thaw, issue queue thresholds) の解説文書ページも参照されたい。これらの値は Drupal.org の Dashboard にある「Contributor Links」ブロックにも表示されるようになったので、簡単にチェックできる。
(これらの措置を通して) 僕たちが望んでいるのは、将来の Drupal リリースにおける革新性と、今日における Drupal リリースの安定性とのバランスをとれるだろうということだ。それによって Drupal 7 がさらに広く採用されていくのを促進することにもなるだろう。