第14章 問題を報告する

効率的なバグの報告は PostGIS の開発を助ける本質的な方法です。最も効率的なバグ報告は、PostGIS 開発者がそれを再現できるようにすることで、それの引き金となったスクリプトと検出された環境に沿った全ての情報を含んでいるのが理想です。SELECT postgis_full_version() [PostGIS]とSELECT version() [PostgreSQL]とを実行することで十分に良い情報を得ることができます。

最新版を使っていない場合にはrelease changelogをまず見て、既にバグフィクスされていないかを探すのは価値のあることです。

PostGIS bug trackerを使うと、レポートが捨てられず、それの対応プロセスが通知されることを保証します。新しいバグを報告する前にデータベースに問い合わせて、既知のバグかどうかを見て下さい。既知のものでしたら、それに関して持っているあらゆる新しい情報を追加して下さい。

新しいレポートを記入する前に Simon Tatham さんのHow to Report Bugs Effectivelyに関するページを読むと良いでしょう。

文書は、ソフトウェアの機能と挙動を正確に反映するべきものです。正確でない場合は、ソフトウェアのバグがあるか、または文書に誤り若しくは不十分な箇所があることが考えられます。

文書の問題もPostGIS bug trackerに報告することができます。

訂正が小さいものなら、バグトラッカの新しい問題の中に、文書内の位置を特定して記述して下さい。

変更が大きい場合は、パッチが確実に好まれます。Unix 上で次の 4ステップの処理を行います (既にgitをインストールしていると仮定します)。

マニュアルの編集または構築の前にレポジトリーの documentation development guide を読んで下さい。マニュアルで使用する実行例、図の生成、評価、HTML、PDF の手順を説明しています。