のようです Canonicalはコメントの多くを考慮に入れています コミュニティだけでなく、開発者によっても作成されました。数日前、 メーリングリストを通じて そのことを知らせた 中間LTSバージョンを準備するプロセスを変更することを決定しました 正確な期限を守ることを犠牲にしてバージョンの品質を向上させることを目的とした、Ubuntuの（たとえば、20.04.1、20.04.2、20.04.3など）。
以前の暫定バージョンが計画された計画に厳密に従って作成された場合、すべての修正のテストの品質と整合性が優先されます。
変更は、過去のいくつかの事件の経験を考慮して採用されました。 その結果、最後の最後に修正が追加され、検証のための時間が不足したため、リリースで問題の回帰的な変更または不完全な修正が発生しました。
私たちのプロセスと品質を向上させるために 20.04.3（XNUMX月）から始まるスポットリリースLTS画像 少し安全なアプローチを試みます。 基本的に主な顕著な変化 これで、どのような場合でもSRU手順に従います。 XNUMX回限りのリリース週に見つかったリリースブロッカー。 この つまり、いくつかの非常に例外的なケースに加えて、各修正（ ブロッカー）は、同じ検証、回帰に従う必要があります 分析プロセスとエージング期間。この場合、エラーが見つかった場合 候補後の画像では、ポイントを遅らせるだけです 修正が確認され、エージングされてから投稿されるまでリリースします 更新。
ポイントのリリースを遅らせるのは残念ですが、ポイントを減らすよりはましです
品質基準。
これで、 彼らは基本的にそれを述べています Ubuntu 20.04.3 XNUMX月の更新時点で、 起動クラッシュとして分類されたバグ修正 予定されている発売のXNUMX週間以内に作成 起動時間が変更されるため、急いで修正を押すのではなく、すべてを徹底的にテストおよび検証できます。
つまり、エラーが見つかった場合 リリース候補のステータスを持つビルドでは、 修正のすべての改訂が完了するまで、リリースは延期されます。
土壇場での修正がスピードアップするケースがすでにいくつかありました 時間のプレッシャーの下で、それらは十分に徹底的にテストされておらず、導入されました 回帰（または、同様に迷惑な、部分的であるように見えた 段取り）。 品質はUbuntuバージョンの最も重要な側面であるため、 ユーザーが私たちから最高の体験を得られるようにしたい スポットリリース画像。
この変更に適応し、リリースブロッカーの数を最大にするため できるだけ早く見つけたら、提案も変更します シリーズの毎日の画像のは、リリースの2週間前に編集されています（ 候補画像が最初のリリースで計画されるXNUMX週間前）。
以前は、毎日の画像を最大XNUMX週間まで提案できるようにしていました ローンチ前（候補者をローンチするときにのみ無効にします 構築されている）、主に、として提案されたときの昔からの遺産として プロセスの一部としてすべてが更新されました。 これは持っていません （安全ではなくなったため）すでに何年も行われているので、そのままにしておきます 新聞での提案は以前ほど意味がありません。
リリースをブロックする問題を早期に検出するために、デイリービルドのフリーズ時間をリリースのXNUMX週間前からXNUMX週間前に増やすことも決定されました。つまり、最初のリリース候補がリリースされる前に、デイリーフリーズをテストするための追加の週があります。ビルドします。
最後に、 Ubuntu21.04ドックがフリーズしたことが発表されたことも注目に値します 新機能（Feature Freeze）の導入から、すでに統合されているイノベーションを完成させ、エラーを特定して排除することに焦点が移りました。
あなたがそれについてもっと知りたいのなら、 あなたは相談することができます 次のリンク。