回答:
NN は正しいですが、例を挙げましょう。
Ubuntuのバージョンがリリースされ、安定していると見なされた場合、安定したリリースの更新はアーカイブにアップロードされません。だから、安定したリリース更新プロセスを経て「提案された」ポケットにアップロードされるソフトウェアの一部が更新を必要とするとしましょう。（リンクされたドキュメントのステップ4）：
バグ報告のパッチ、詳細でユーザーが読み取り可能な変更ログ、および他の無関係な変更がないリリース修正案に修正パッケージをアップロードします。
更新の一部のリストを以下に示します。次に、提案されたセクションを有効にした人（アップロードした人を含む）がそれをテストします。これには通常、約1週間かかります。
その後、更新は通常の更新チャネルを介してプッシュされ、更新マネージャーを介して取得されます。基本的には、一般に公開される前にアップデートをテストする場所にすぎません。
詳細：
基本的に、メインリポジトリにリリースされる前のパッケージ（およびより一般的なパッケージバージョン）のテストの場です。したがって、通常の更新ルールが適用されます。厳密に必要な場合を除き、これを介して深刻なバグ修正とセキュリティパッチのみを取得します。
有効にすると、完全にテストされる前に物事を取得します。私の経験では、Ubuntuのアルファ版またはベータ版ほど不安定ではありませんが、そうなる可能性があります。そのため、おそらく、パッケージに関するフィードバックを提供するために存在する場合にのみ使用する必要があります。おそらく本番マシンでは使用しないでください。
tl; dr、必要がない限り使用しないでください。
リポジトリに関するコミュニティのドキュメントによると、提案されるリポジトリは次のとおりです。
更新のテスト領域。このリポジトリは、更新のテストとフィードバックの提供に関心がある人にのみお勧めします。
バックポートに関するコミュニティドキュメントによると、提案されたリポジトリは次のとおりです。
-updatesのテスト領域。-updatesを許可する前に、多くの人々がこれらのパッケージに肯定的なフィードバックを与える必要があります。このリポジトリは、更新のテストとフィードバックの提供に関心がある人にのみお勧めします。それらは実際に更新をテストしているため、このリポジトリに欠陥のある更新がある可能性が高くなります。
このスレッドとそのリンクも参照してください。