GNU Emacsを改善するためにバグfixを書きたいなら、それはとても助けになります。変更を送るとき、メンテナーがそれらを使うのが簡単になるように、どうか以下のガイドラインにしたがってください。これらのガイドラインにしたがわない場合でも、あなたの情報はまだ有用でしょうが、それを使用するのに余分な作業が必要になります。GNU Emacsの保守は最良の状況でも多くの作業を要すので、わたしたちを助けるのにあなたがベストをすくさなければ、わたしたちはそれを維持できないのです。
各パッチは、わたしたちがそれを正しく評価するために、簡単な情報をもたなければなりません。これらの情報については以下で説明します。
それらの情報がすべて揃ったら、M-x submit-emacs-patchコマンドを使ってパッチを送信してください。このコマンドはそのパッチの件名とパッチファイルの入力を求めます。それからパッチファイルが添付されたMessageモードのバッファーを作成、表示してそのパッチに関するより詳細な説明、それから以下で求めるようなその他の情報を追加できるようにします。それらが終わったらC-c C-cをタイプして、電子メールで開発者にパッチを送信してください。そのメールはhttps://debbugs.gnu.orgにある、GNU Bug Trackerに送信されるでしょう。Trackerはバグレポートに行うように、あなたの投稿に番号を割り当てます。通常だと開発者が返信することになるので(さらなる詳細や追加の情報を求めるためかもしれません)、必ず有効な返信用のメールアドレスを含めるようにしてください。
パッチの投稿の一部としてわたしたちが提供して欲しいのは以下の情報です:
If you make two changes for separate reasons, then we might not want to install them both. We might want to install just one, or install them separately in different versions of Emacs. If you send them all jumbled together in a single set of diffs, we have to do extra work to disentangle them—to figure out which parts of the change serve which purpose. If we don’t have time for this, we might have to postpone inclusion of your patches for a long time.
1つの変更を記述したら、その変更の説明と一緒にそれをすぐに送れば、2つの変更は混ざることはなくなり、それらを区別する余計な作業なしに、わたしたちはそれぞれを正しく判断することができます。
変更は個別に送るべきなので、すぐに送ることができるでしょう。これは、その変更が重要なものなら、それをすぐに採用するオプションをわたしたちに与えます。
git
pullなどにより)最新であることを確認してください。あなたの変更をプライベートのブランチにコミットして、git format-patch
masterを使用することにより、マスターバージョンからパッチを生成できます(パッチの適用が容易になるので、これが推奨する方法)。または以下で述べるように変更をコミットせずに、git
diffを使用することもできます。
diffを作成する際にはどちらが古いバージョンで、どちらが新しいバージョンか、あいまいになるのを避けてください。どうかdiffの第1引数に古いバージョン、2番目の引数に新しいバージョンを指定してください。そして一方のバージョンにたいして、それが古いバージョンなのか、変更した新しいバージョンなのかを示す名前をつけてください。
コミットログはその変更の根拠、あなたのパッチが修整を試みる問題を変更後のコードがどのように解決するかを説明して、更に人々がその変更をどこで見つけられるかを示すことが目的です。したがって変更した関数とその理由を具体的に記す必要があります。適切なコミットログメッセージにたいするわたしたちのスタイルと要件については、どうかEmacsソースツリーにあるファイルCONTRIBUTEのセクション“Commit messages”を参照してください。
どのような種類の情報を記述するかを見るために、最近のコミットにたいするコミットログエントリーも参考にして、わたしたちが使用しているスタイルを学んでください。他のプロジェクトとは異なり、たとえばTexinfoファイルのようなドキュメントにたいするコミットログも必要です。変更ログ、および Change Log Concepts in GNU Coding Standardsを参照してください。
一般的には改善となるかもしれないが、そう確信するのは難しいようなfixを送る人が、ときどきいます。そのような変更を採用するのは、わたしたちがそれをとても慎重に調べなければならないので、難しくなります。もちろん、その変更が正しい理由の説明は、わたしたちを納得させる助けになります。
もっとも安全な変更は、特定の機種やシステムで使用されるファイルやファイルの一部にたいする変更です。これらの変更は、新しいバグを他の機種やシステムに作成しないので安全です。
インストールの安全性が明確な形式でパッチをデザインして、わたしたちの作業量を、良い状態に保つ助けとなってください。