GNU Emacsに対する改良や虫取りのための修正を送ろうということであれば、 おおいに助かります。 修正を送るにあたっては、保守チームがそれを役立てやすいように、 以下の指針に従ってください。 さもないと、送られた情報は有用であっても、 役立てるには余分な作業が必要になります。 GNU Emacsの保守は最善の環境でやっても手間のかかる仕事ですから、 手助けしていただくにしても十分な配慮が必要なのです。
(バグレポートへのポインタを示すよりも、 バグレポートのコピーを含めるほうが望ましい。 というのは、ポインタだとバグレポートを探す必要があるし、 そのバグを直し終えていると、バグレポートを消してしまっているかもしれない。)
異なる理由に基づいて2つの変更を行った場合、 その両方を採用することはないだろう。 どちらか一方だけを採用するかもしれない。 もしそれらをいっしょくたに1つのdiffにしてしまうと、 それを分離するために余計な作業が必要になる。 どの部分の変更がどちらの目的に対応しているのか調べる必要がある。 その時間を割けないと、その変更をまったく 採用しないということにもなりかねない。
それぞれの変更を行ってすぐに、別個に、説明を付けて送ってもらえれば、 2つの変更が一緒になるなどということはないし、 それぞれの変更を分離するなどの余計な作業をせずに適切に考慮できる。
それぞれの変更は別個に送るべきなので、変更を行ったらすぐに送れるはず。 そうすれば、保守チームのほうでその変更が重要なものだと 判断したらすぐ取り入れることができる。
もしGNU diffを使っているのなら、Cのコードのdiffを作るときには ‘diff -c -F'^[_a-zA-Z0-9$]+ *('’を使う。 こうすると、変更される各関数の名前が一緒に表示される。
変更記録の目的は、人が読んでどこが変わったかわかるようにすること。 だから、どの関数を変更したか具体的に書く。 大きい関数の場合は、関数の中のどの箇所を変更したかも書いてあると助かる。
その反面、どこが変更されたかわかるようにさえなっていれば、 変更の目的は変更記録で説明する必要はない。 たとえば、新しい関数を追加したのであれば、 その関数が新しいということだけを書けば十分。 目的を説明したほうがよいと感じるなら、たぶんそのとおりだろう。 しかし、説明はコード中のコメントに書く。 そのほうが役に立つ。
ディレクトリsrcとディレクトリlispの ファイルChangeLogを眺めて、どのような情報を入れるかとか、 どのようなスタイルで書くかの参考にしてほしい。 誰が変更したかわかるように自分の名前をヘッダの行に記録したいなら、 ヘッダ行も送ること。
ときどき、おおむね改良になるかもしれないが、 はっきり改良だとはいいがたいような変更を送ってくる人がいる。 そのような変更は、きわめて慎重に検討しなければならないので、 採用するのは難しい。 もちろん、あなたがどのような理由でその変更が正しいのかよい説明を 書いてくれれば、保守チームがそれを理解する助けになる。
もっとも安全な変更は、特定のマシンの構成ファイルに対する変更。 それが安全だという理由は、 その変更が他のマシンにおいて問題を引き起こすことはありえないから。
修正を採用しても安全だとはっきりわかる形に設計することで、 保守チームの労力を軽減できる。