現在のリリースに含まれているパッチを入手することは可能ですか？もしそうなら、どのように？

それでしばらく前に、CompizのPlace Windowプラグインのバグを報告しました。これは、影響を受ける人々にとってはかなり大きな後退です。主にレポートによると、Gnome-Fallbackを使用している人々です。

パッチはすぐに浮上しました。テスト用のPPAを作成し、これまでに関係者全員が問題が修正されたと報告しています。さらに別のバグを修正します。私は標準のUnityデスクトップでテストを行いましたが、（私のテストでは）悪影響は見られませんでした。

次の2つの主な理由から、これをUbuntuに今すぐプッシュしたいと思います。

• 私は利己的です。Compizの新しいバージョンが12.04にプッシュされるたびにPPAを更新する必要はありません。
• 愚かな小さなバグのために、Ubuntuユーザーがウィンドウが飛び回っているのを見たくありません。

このパッチをできるだけ早くUbuntuのバージョンのCompizにプッシュして欲しいので、これらのバグを修正済みとしてマークし、私たちの生活を進めていきます。

これを今すぐUbuntuに取り込むには、誰の足をハンプする必要がありますか？

私はこのプロジェクトを維持しておらず、アップストリームのものですが、Ubuntuにはかなり不可欠です。Compizに行くこともできますが、パッチを受け入れた場合、Ubuntuの近くに至るまでに（少なくともリリース）数ヶ月かかると思います。

そして、私が適切な人を見つけたとき、どうすれば彼らのためにプロセスをできるだけ滑らかにすることができますか？

私は彼らに私の要求を見てもらい、「はい、すべてが素晴らしく、完了しました」と言って欲しいです。パッチの側面に対処する17通の電子メールは必要ありません。さらに重要なことに、私も彼らの時間を無駄にしたくありません。

そして、私はそれらを提供する必要がありますか？私のパッケージングスキルは...嘆かわしいです。再配布のためにパッケージにパッチを当てるのはこれが初めてだったので、おそらくすべてのパッケージエラーを人に知られていました。彼らは元のパッチに満足しますか（自分でそれを適用できます）、またはdiff / changelogが少しきれいになるように物を再パッケージ化する必要がありますか？

_{注：この質問は Compiz についてですが、答えが他のスタイルのパッケージにも対応できるようにしたいので、物事を修正する方法の信頼できる包括的なスレッドがあります。}

Dobeyが述べたように、パッチがすでにリリースされたUbuntuのバージョンに受け入れられるためには、Stable Release Update（SRU）プロセスを経なければなりません。SRUの参入障壁は非常に高いです。プロセスの背後にある考え方を要約する簡単な方法は、「私たちが知っているバグは、知らないバグよりも優れている」ということです。実際には、それは、ターゲットを絞ったバグ修正のみが許可され、「侵入的」すぎる変更は許可されないことを意味します。

SRUを続行するには、いくつかの要件を満たす必要があります。

• このバグは、現在の開発リリースで修正されています（クォンタル）。
• バグレポートの説明を更新して、安定版リリースで修正が必要な理由の正当性、バグを再現して修正されたことを検証するテストケース、修正のリグレッションの可能性に関する議論を含める必要があります。
• Launchpadチームubuntu-sruは、バグレポートを購読する必要があります。
• その後、パッケージがリリースにアップロードされ-proposedます。これを実現するには、スポンサーシッププロセスを実行する必要があります（詳細は以下を参照）。

すべての問題が発生した後、SRUチームはパッケージが-proposedバグを解決することを確認します。その後、パッケージは-updates最低7日間のエージング期間を過ぎた後にプッシュされます。

適切な人を見つける

あなたの質問は、時々Launchpadがパッチが死ぬ場所のように見えるという事実を示唆しています。悲しいことに、プロセスがわからない場合、そのように感じることがありますが、私はそれがそれほど悪くないことを誓います。幸いなことに、知っておくべき主なことは簡単です。すべての詳細といくつかのヒントについては、スポンサーシッププロセスをご覧ください。ただし、最も重要な部分は、ubuntu-sponsorsチームをバグレポートに登録することです。これにより、スポンサーシップキューに表示され、誠実なUbuntu開発者に見られるようになります。

リアルタイムで何かを話す必要がある場合は#ubuntu-devel、FreenodeでIRCがトリックを行います。現在のパッチパイロットのチャネルトピックを確認してください。彼らはあなたを助けるためにそこにいます。パイロットが勤務していない場合は、チャンネルでお気軽にお問い合わせください。ただし、しばらくお待ちください。

すべてを準備する

プロセスをできるだけ早く実行するために、いくつかの作業があります。

バグの説明を次のように更新します。

[影響]

バグがユーザーに及ぼす影響の説明と、安定版リリースへの修正のバックポートの正当性

[テストケース]

1. ステップ

2. 沿って

3. ステップ

4. 説明書

5. 検証します

6. 修正

[回帰ポテンシャル]

回帰の可能性について説明します。

[元のレポート]

説明に使用されていたすべてのものは、以下に保持されます。

次に、パッチを準備します。上流のソースに対するパッチではなく、すべてのパッケージングビットを処理するdebdiffを提供すると、事態はずっと速くなります。これには、パッケージパッチシステムが使用されている場合はそれを使用することも含まれます。幸いなことにadd-patch、ubuntu-dev-toolsがあなたのためにそれを処理してくれます。

これを見ていきましょう。まず、バグレポートのソースとパッチを取得します。

$ pull-lp-source compiz precise
$ wget https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/974242/+attachment/3141645/+files/fix-974242.patch 

次に、ソースパッケージにパッチを追加します。

$ cd compiz-0.9.7.8/
$ add-patch ../fix-974242.patch

これはにパッチを追加しdebian/patchesて実行dchするための新しいエントリを追加するプロンプトを表示debian/changelog提案をターゲットとし、それは開発版リリースにアップロード次のバージョンの下になるようにバージョン番号をインクリメントするエントリを調整します。そのようです：

compiz (1:0.9.7.8-0ubuntu1.1) precise-proposed; urgency=low

  * debian/patches/fix-974242.patch: [DESCRIBE CHANGES HERE]

 -- Your Name <you@example.com>  Mon, 11 Jun 2012 17:37:59 -0400

のファイルにdebian/patches/fix-974242.patchは、編集する必要のあるヘッダーもあります。

## Description: add some description
## Origin/Author: add some origin or author
## Bug: bug URL

次に、新しいソースパッケージをビルドします。

$ debuild -S -us

そして、debdiffを作成します。

$ cd ..
$ debdiff compiz_0.9.7.8-0ubuntu1.dsc compiz_0.9.7.8-0ubuntu1.1.dsc > sru-for-lp-974242.debdiff

これで、結果のdebdiffファイルをバグレポートに添付できます。

12.04に出荷するには、安定リリースアップデートが必要です。受け入れられる修正の種類、およびそれらを取得する手順については、https：//wiki.ubuntu.com/StableReleaseUpdatesを参照してください。