間に 最近の開発者会議 オーストリアのグラーツで開催された KDEプロジェクトチームは重要な決定を下した それはそれです プログラムは終了する 長期的なサポート KDE Plasma 用 (LTS)。 今後は、ディストリビューションが選択した場合、デスクトップのレガシー バージョンを保守する責任を負い、バグの追跡と修正の適用を独自に行うことになります。
これまで適用されたLTSモデルは、 KDE エコシステムの一部のみをカバーしました。 Plasmaデスクトップ環境にはLTSブランチがありましたが、このサポートは フレームワークやアプリケーションには適用されなかった プロジェクトのメンテナンス作業の大部分をディストリビューションに任せています。多くの場合、ディストリビューション開発者はすでに完全なサポートを提供するために多大な努力を払っており、現在のモデルは断片化され非効率的なものになっています。
さらに、 古いバージョンの維持には追加の負担が伴う プロジェクト開発者向け。 LTS ブランチのバグを修正するには、ディストリビューション固有のグラフィック スタックの違いやメインの KDE リポジトリとの同期が取れていないことが原因で再現できない問題に対処する必要があることがよくありました。これと、「LTS」という用語によってユーザーの間で生じた安定性への期待が相まって、チームは戦略を真剣に再考することになりました。
新しいアプローチ：より長持ちする通常バージョン
個別のLTSブランチを作成する代わりに、 KDEはより機敏なメンテナンスモデルを採用する しかし同様に堅牢です。 通常の Plasma リリースには、6 つのメンテナンス アップデートが含まれます。 通常の 5 回ではなく、これによりライフサイクルが延長されます。また、メジャーリリースの頻度を年間 3 回から 2 回に減らし、各バージョンを拡張サポート付きの一種の「ミニ LTS」として機能させる可能性も検討されています。
この変化 貴重な資源を解放し、 非常に特殊な環境に依存する古いバージョンを維持するのではなく、現在の再現可能なバグを修正することにチームの努力を集中させます。ただし、開発サイクルを延長するという提案は、Wayland への完全な移行に関連するさまざまな問題が解決されるまで、まだ評価中です。この議論は、4 か月後の次の Akademy 会議で再開される予定です。
当社の Plasma LTS (長期サポート) 製品が優れていないことは周知の事実です。これは実際には、古いブランチに留まったりテストしたりすることを好む Plasma 開発者がいないため、通常よりも長い期間にわたってバグ修正を展開し、通常はテストも行いません。さらに、フレームワークやギア アプリケーションに相当する LTS 製品が存在しないため、LTS コンセプトには多くのギャップが残っています。さらに、「LTS」の意味は人によって異なります。多くの人は、この用語を広範囲に定義しており、それが実現不可能な安定性への期待を生み出しています。
当社は、製品の限定的な性質が誰の期待にも応えられなかったと結論し、製品を中止することにしました。代わりに、追加のバグ修正リリースを追加することで、通常の Plasma リリースの有効なサポート期間をわずかに延長し、サポート期間を 5 日から 6 期間にします。
より透明性の高い参加型テレメトリ
別の変更 開発者会議で発表されたのは テレメトリーシステムの改革これはオプションのままですが、より参加型で具体的なアプローチが採用されます。新しいメカニズムは Steam ハードウェア サーベイ モデルにヒントを得たもので、ユーザーはダイアログ ボックスを介して特定の調査への参加を招待され、参加を承諾または拒否する前に、収集されるデータを正確に確認できます。
この制度 開発者がより良い情報に基づいた意思決定を行えるようになるKWin の特定の視覚効果がまだ使用されているかどうかを確認してから、削除するかどうかを決定する方法。各調査には匿名化された統計を含む公開概要が添付され、ユーザーは将来の招待をいつでも拒否することができます。
そうすべき LTSサポートの撤回は放棄を意味するものではないことに注意する必要がある。 安定へのコミットメントの より現実的で持続可能な戦略への転換 KDE のように大規模でモジュール化されたプロジェクトの場合。より合理的なメンテナンス サイクル、より効果的なエラー処理、明確で自発的なテレメトリにより、KDE は実際のユーザーのニーズへの応答性を向上させることを目指しています。