| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GCC について、バグ修正や改善を書いてくれるなら、
それは大変役に立つことである。修正案はパッチ用メーリングリスト
gcc-patches@gcc.gnu.org に送って欲しい。
以下の指針に従って、読者のパッチを我々が効率良く 調べることができるようにして欲しい。これらの指針に従ってもらえないと、 読者の情報が有益なものであっても、それを使うのに余分な仕事が必要に なってしまうのである。GNU C を保守することは、最善の環境にあっても たくさんの作業を必要とするので、読者にも最善を尽くしてもらわないと 維持するのが困難である。
(バグレポートを単に参照するのは、同封するのには劣る。なぜなら、参照の場合 だと、我々はそれが指しているものをまず探さなければならず、既にその レポートのバグが修正済みであると、既にバグレポートを削除してしまっている 可能性があるからである。)
別々の理由で二箇所変更を行った場合、我々はその両方はインストールしたく ないこともある。どちらか一つだけインストールする可能性がある。 両方を一個の差分に混在させると、変更のどの部分がどの目的に対応した修正 なのかを見るために、それをより分けるという余計な手間が 必要になる。我々にそのための時間がない場合、読者の変更を全部無視 せざるを得なくなることもある。
それぞれの変更を書いてすぐに、説明を付けて送れば、二つの変更が 混じり合うことは無いはずであり、我々はより分けるという余計な作業を せずともそれぞれの変更を正しく考察できることになる。
理想的に、は読者が送ってくる変更はそれぞれ、我々が別々に検討したいと 思うような部分にさらに分割するのは不可能であるぐらいにして欲しい。 分けられるとすると、そのそれぞれの部分は他のパートからの影響を 受けてしまうからである。
それぞれの変更を別々に送るべきなのであるから、同様にすぐそれを 送るのが良いのである。そうしてくれると、それが重要なものであれば、 直ちに我々がインストールできる可能性が出てくるのである。
GNU diff が使えるなら、‘diff -cp’ として、それぞれの変更点のある 関数名を表示するようにしてほしい。
‘ChangeLog’ ファイルを読んで、どういう種類の情報を書くべきか、 どういう形式で書くべきかを見て欲しい。どの関数を変更したかについて 明示する必要がある。大きな関数の場合は、その関数のどの辺を変更したかを 示して貰うと大変助かる。
一方、変更した箇所がどこかを一度示せば、その目的を説明する必要はない。 つまり、新しい関数を一個追加したなら、それについて述べるべきことは その関数が新しいものだということだけである。その目的を説明する必要が あると思ったなら、多分そうすべきなのだろう。だが、それは、コード中の コメントで説明したほうがもっと役に立つだろう。
誰が変更を行ったかを示すヘッダ行に読者の名前を出して欲しければ、 そのためのヘッダ行を送って欲しい。
ある問題を解決するのに、‘toplev.c’ のような機種に依存しない ファイルを変更して、特定のシステムが必要とする特殊な処理を行なうように してはどうかと提案する人が時々いる。時には、そのような変更がほとんど 全てのユーザにとって GCC を破壊するのが明らかなこともある。 我々はそのような変更を行なうことはできない。良くても、受け入れられる 形で問題を解決する別のパッチの書き方を我々に教えてくれるだけになるだろう。
人は良く、汎用的な改善に違いないという修正を送ってくるが、 それを確認するのは難しい。そういう変更をインストールするには、 非常に注意深くその変更を調べなければならないので、困難なのである。 もちろん、その変更が正しいと読者が結論づけた理由をうまく説明 してくれれば、我々が確認する助けとなる。
最も安全な変更は、ある特定のマシン向けのコンフィギュレーションファイルに 対する変更である。何故なら、他の機種に対しては新しいバグを作り出す ことはありえないからである。
インストールするのに都合が良い形になるようにパッチを作るようにして、 我々の作業負荷を増やさないようにお願いする。
This document was generated
using texi2html 1.78.