Drupal 8 リリース スケジュールのリスクを減らす（後半）

（この記事は長いので前半と後半に分けました。前半はこちら）

該当するメタ イシューは（Drupal 8 の）リリースにとって重大ではないと見なされるけれども、その一部を Drupal 8 と一緒に出荷（リリース）できるという場合も、それら（そのメタ イシューの一部）ができ次第、パッチをコミットしていくつもりだ。Views の変換がこのいい例だ。管理用ページをすべて Views に変換して Drupal 8 を出荷できたらステキだろうとは思うが、一部のページだけを変換して出荷することもできる。

そのパッチがより大きな、重大ではないメタ イシューの一部で、そのまた一部分を仕上げるというのは、該当する部分全体を全く仕上げないのよりも悪い（未完成な状態は Drupal 8 のリリースに待ったをかけることになる）。そうなると、僕たちは「危険地帯」にいるわけなので、可能な選択肢に目を向けなくてはならない：

1. まず、そのパッチを作り直すなり部分的に切り離すなりして自己完結型のイシューにできないか検討してみるべきだ。そうすれば（それが可能なら）そのイシューのパッチは通常の手続きに沿ってコミットできる。
2. 該当するイシュー全体を完結させる以外に選択肢はないという場合、コア メンテナーたちは各チームと協力してそれぞれの作業の「切り捨て期日」を決定する（それによって 7 月 1 日までに統合する時間が十分とれる）。同時に、リリースに足止めを食わせることなしに作業を続ける最も安全（確実）な方法も決める。可能な方策としては次のようなものがあるだろう。
   • （CSS 再構成など）パッチベースのワークフローを利用することがまだ適しているところでは、そのメタ イシュー全体を含む大型のパッチ。フォローアップ（フォローするパッチ群）はなし。
   • （Twig など）大規模な変換作業の場合、Drupal コアのリポジトリーを分岐し、それが許容できるレベルに達したと見なされた段階で、それを取り込む（マージする）。
   • （SCOTCH など）大規模なリファクタリング（プログラムの振る舞いを変えることなくソースコードを変更すること）がまだ必要なところでは、サンドボックス プロジェクト。

「切り捨て期日」までに作業が全体的に完了した（すなわち、アップグレード パスも機能し、すべてのコア ゲート（審査）を通った）なら、それは Drupal 8 にふさわしいことになる。しかし、間に合わなかった場合、それは Drupal 9 へと先送りされなくてはならないだろう。これだけ頑張ってきたのに間に合わなかったというチームにとっては間違いなく痛いことだが、Drupal 8 のリリースを無期限に遅らせるよりはましだ。

まとめ

結論として、これから僕たちが Drupal 8 にコミットするパッチはすべて（Drupal 8 を）出荷可能な状態へ向けて進めなくてはならない。すなわち、きちんと機能しなくてはならないし、パフォーマンスもよくなくてはならない（または、よりパフォーマンスのいいコードに向けて必要な踏み台にならなくてはならない）。また、説明文書も整っていなくてはならないし、十分にテストされていなくてはならない。さらに、適切なデベロッパー エクスペリエンス（DX）を提供しなくてはならない。Drupal 8 をリリースできるようにするには大きな努力が必要だ。コア コントリビューターたちはありとあらゆる助力の手を利用したいところだろう。今こそ（その作業に）参加して手伝う時だ。