開発プロセスの改善提案
「Lubuntu」の開発者が「Ubuntu」及びフレーバーの開発プロセスの改善提案を行っています。現在のリリースサイクルとBionic Beaver
「Ubuntu」の開発プロセスでは「最終β」リリース前に、「α1」「α2」「β1」の3種類のリリースが定義されています。「Ubuntu」はこれらの段階でリリースを行っていませんが、リリースを行うと表明したフレーバーがこれらの段階でリリースを行っています。
正式リリース前のリリースはテスト目的のために行われるリリースであり、テスターは各リリースで提供されるディスクイメージを利用してテストを行います。
さて「Bionic Beaver(18.04の開発コード)」の開発では、「Spectre/Meltdown」の対応に時間が割かれ、「α1」及び「α2」のリリースが行われませんでした。
また「Lubuntu」では、これにより十分なテストが行えなかったため致命的な不具合を検出できず、「Lubuntu 18.04 β1」は不具合によりリリースを見送ることになりました。
デイリービルドのディスクイメージとリリースされるディスクイメージ
デイリービルドのディスクイメージは、毎日ビルドされるディスクイメージです。「α1」等でリリースされるディスクイメージは、デイリービルドのある時点でのスナップショットに相当します。
α1の例
例えばあるフレーバーが「α1」をリリースしたとします。「α1」はリリース日に合わせたソフトウェア(パッケージ)で構成されています。「α1」でリリースされるディスクイメージは、安全にインストールできるものとされています。
「α1」でリリースを行ってもその後不具合の修正やパッケージのアップデートなど開発作業が続きます。
作業の成果は、日々生成されるディスクイメージに反映されていきます。
そして日を追うごとに、OSの品質が正式リリースで期待される品質に近づいていきます。
そのため「α1」リリース後すぐに不具合の修正が反映されたデイリービルドのディスクイメージを提供することも可能ですが、それらが「α1」のディスクイメージに反映されることはありません。
proposedポケットとreleaseポケット
アップロードされたパッケージが即座にユーザーに提供されるわけではありません。必ずテストを行い、既存の他のパッケージやシステムに影響を与えないことを確認する必要があります。
アップロードされたパッケージは「proposed」ポケットに配置され、その後テストに合格すれば、そのパッケージが「release」ポケットに移されます。
「release」ポケットに移されたパッケージはアップデートとしてユーザーに提供されます。
つまり「release」ポケットに配置されているパッケージは、常に正常にインストール可能で正常に動作するパッケージが配置されます。
この仕組みや、「proposed」ポケットから「release」ポケットにパッケージを移すための手続きは、以下で定義されています。
またデイリービルドのディスクイメージとリリースされるディスクイメージに含まれるパッケージは、「release」ポケットに配置されているパッケージです。
これらを踏まえ、リリースされたディスクイメージに対してテストを行うよりも、継続的にアップデートされたパッケージに対してテストを行った方が、効果的に取り組めるのではないか、とのことです。
αリリースとβ1リリースをやめよう
提案内容は、既存のαリリースとβ1リリースを止め、代わりに毎月テスト週間を設けることです。テスト週間は、月のある週の火曜日から木曜日に設定されます。
テスト週間をどの週に設定するのかは、「Freeze」などプロセスの区切りや状況を見て判断されます。
またテスト週間中にパッケージバージョンを固定することはありません。
また開発チームは、αリリースとβ1リリースが無くなることでリリースにかかるコストを削減できるだけでなく、より実際的なテストを行うことができます。
すでにいくつかのフレーバーとは本件に関しアイデアを共有しており、好意的な反応を得ています。
もし本提案が通れば、この新しいプロセスは「18.10」から適用されることになるでしょう。
また具体的なプロセスについても、「18.10」で明らかになるでしょう。