STP への参加と貢献

パッチ形式による貢献と拡張を歓迎しております。次の簡単なガイドラインに従って頂ければ、すべてが順調に進みます。

はじめにお読みください

• 変更点を十分にテストします
• 行った作業を文書化します
• シンプルに行います
• パッチを http://sourceforge.net/projects/stp/ にアップロードします。

• すべてのパッチが受け付けられるとは限りません

ヒントとコツ

• 動作に疑問な点がある場合、BUGS、WISHLIST、PLAN の各ドキュメント、あるいは SourceForge の該当するサイトで、その問題がすでに発生し、すでに対策がとられているかどうかを調べます。

開発手法

このアプリケーションの一般的な開発の優先順位は次のようになっています。

1. 可読性
2. 保守性
3. 堅牢性
4. パフォーマンス

このプログラムは、進化的手法で開発されています。つまり、コードはリリースのたびに改良され、設計全体がより高度なものになります。ただし、すべてのリリースステップにおいて、コードは使用可能でなければなりません。

考慮すべきもっとも重要なことは、テスト結果には一貫性と再現性がなければならないということです。このことから、ハードウェア構成、ソフトウェア一覧、カーネルとライブラリのバージョンなど、テストの実行環境に関するすべての情報の追跡と保存を、非常に入念に行う必要があります。

既存コンポーネントへの追加

このプログラムに対する変更は、パッチでの提出をお勧めします。パッチを作成するには、「diff original changed > patch」と入力します。複数のファイルやディレクトリツリー全体のパッチを作成することもできます。詳細については、「man diff」を参照してください。

変更点を十分にテストしてから、提出してください。必要に応じて、スペルチェッカ、構文チェッカ、コンパイラをファイルに対して実行します。少なくとも t/ ディレクトリ内のテストを全部実行し、何も壊していないことを確認します。パッチを作成したら、全体に目をとおして、パッチが意図したとおりに動作することを確認します。念のため、他の人にもパッチをテストしてもらいます。

バグを修正した場合、将来自動的に検出できるように適切な回帰テストを追加してください。機能を追加したり変更したりした場合は、適切なユニットテストを追加またはアップデートします。ファイルの追加や削除などによりビルドプロセスを変更した場合は、パッケージ生成もテストしてください。

Changes ファイルに修正点のコメント、AUTHORS ファイルに名前を追加し、TODO や BUG にコメントを追加します。データベーススキーマを変更した場合は、ドキュメントや図表をアップデートし、これらの変更を反映したスクリプトを作成します。

パッチは SourceForge インターフェースを介して提出します。これができない場合は、保守担当者まで電子メールで送信します。パッチについての簡単な説明を添えるようしてください。

パッチが理解しやすく実装が容易なほど、早期にコアに実装される可能性があります。コードベースに対して概念的に異なる変更を実行する各パッチを作成します。1 つの大きなパッチではなく、小さなパッチの集合で送っていただくことをお勧めします。これにより、各パッチの審査とテストを個別に行うことができます。

既存コンポーネントの大幅な変更を希望される場合は、保守担当者と調整してください。まず、計画の概要を提出し、定期的 （2 - 3 週間に 1 度） に連絡をとり、提出する準備が整ったら、その旨通知します。これを受けて、保守担当者は変更の受け取りと実装の準備を行います。

新規コンポーネントの追加

新規アイテム追加のプロセスは、既存アイテムの変更とほぼ同じですが、さらに、次の質問に答えるドキュメントを作成する必要があります。

• 目的
• 作成した理由
• 使用方法
• キーアルゴリズムの場所と働き
• 改善点

可能であれば、新規コンポーネントをこのアプリケーションの一部として提供すべきか、それとも独立したエンティティとして取り扱うべきかをあらかじめ検討して、そのための保守管理を自ら行います。

機能の削除、アーキテクチャの変更、インターフェースの変更

コマンドラインオプション、プロトコル、メインプログラムのコンポーネント間の API の変更、モジュールのロードおよび対話方法の修正に関しては、変更の前にあらかじめ説明と審査が必要です。保守担当者に、その変更の動機、および必要性と利点の詳細を報告します。何を欠点または弱点と考えているのか、そしてそれらはどのようにして軽減されるのか、その利点は変更するに値するのかを明らかにします。

リリースストラテジー

下位互換性を損なう可能性がある変更を含むインターフェースの修正が行われた場合に、メジャーリリース番号が増えます。バグフィックスや小さな機能の追加が行われた場合に、マイナーリリース番号が増えます。

原則は、早期にリリース、頻繁にリリースです。つまり、機能が変更されるたびに新規リリースは更新されます。

スタイルガイドライン

コードを直接ハッキングする場合は、コードベースの他の部分との一貫性を維持し、実装に必要なリフォーマット作業を最小限にするために、次のガイドラインに従ってください。

一般には、既存のコアコードと一致させるようにします。

ディレクトリの命名規則

• ディレクトリ名には小文字を使用
• 長さは 14 文字以下

ファイルの命名規則

• ファイル名にはすべて小文字を使用
• 長さは 14 文字以下
• コマンドラインで実行可能なスクリプトには拡張子を付けない
• 他のプログラムによって解釈またはロードされるスクリプトには標準拡張子（.pl、.sh など）を付ける

関数の命名規則

• 関数名の単語間はアンダースコア（_）でつなぐ
• プライベートメンバー関数名には先頭にアンダースコアを 1 つ付ける

変数の命名規則

• 定数にはすべて大文字を使用
• 通常の変数にはすべて小文字を使用
• メンバ変数名には m_ を先頭につける

変更ログの規則

• チェックインするすべての変更について変更ログ項目を記入します。標準の変更ログのフォーマットを使用します。現在の Changes ファイルの例を参照してください。

最後に

上記のいかなる事項も、COPYING ファイルに明示されている、修正および再頒布の権利に対して何らの影響や制限を与えるものではありません。しかし、これらの事項に従って頂くことにより、保守担当者管理者の仕事がはかどり、プログラムのソースやドキュメントを整然とした最新の状態に保つことができます。

Copyright (C) Bryce Harrington. 本ファイルは GPL、GFDL、LGPL、BSD、および Artistic ライセンスの条項の下で使用することが許可されています。