」のコミットログとして簡単に引用できる形で書けば、メンテナから感謝されるでしょう。説明が長くなりだしたのであれば、おそらくそれはパッチを分ける必要があるという兆候です。パッチ(シリーズ)を(再)投稿する時、十分なパッチの説明とそのパッチが必要な理由をパッチに含めてください。N」とだけ書かないでください。参照する手間をかけさせないでください。パッチシリーズとその説明は一緒にあるべきです。これはパッチをマージする人、レビューする人、どちらのためにもなります。レビューする人の中には、おそらく過去のバージョンのパッチを受け取ってもいない人がいます。意味のあるひとまとまりごとに変更を個々のパッチファイルに分けてください。化の両方の変更を含んでいるのであれば、その変更を2つ以上のパッチに分けてください。使う新たなドライバーが含まれているなら、2つのパッチに分けてください。一方で、もしあなたが多数のファイルに対して意味的に同じ1つの変更を加えるのであれば、その変更を1つのパッチにまとめてください。意味的に同じ1つの変更は1つのパッチの中に含まれます。あるパッチが変更を完結させるために他のパッチに依存していたとしても、それは問題ありません。依存している」と簡単に注意書きをつけてください。パッチをより小さなパッチの集合に凝縮することができないなら、まずは15かそこらのパッチを送り、そのレビューと統合を待って下さい。カーネルの)コーディングスタイルに違反していないかをチェックして下さい。見つけることができます。コーディングスタイルの違反はレビューする人の時間を無駄にするだけなので、恐らくあなたのパッチは読まれることすらなく拒否されるでしょう。)を利用してパッチをチェックすべきです。パッチに違反がのこっているならば、それらの全てについてあなたは正当な理由を示せるようにしておく必要があります。ファイルとソースコードに目を通してください。更がメンテナのいる特定のサブシステムに加えられるものであることが分かれば、その人に電子メールを送ってください。)へパッチを送ってください。ほとんどのカーネル開発者はこのメーリングリストに目を通しており、変更に対してコメントを得ることができます。カーネルに入る全ての変更に対する最終的な意思決定者です。彼は多くの電子メールを受け取っているため、できる限り彼に電子メールを送るのは避けるべきです。しなければなりません。