1. 開発の方針、ルールについて
    1. OpenHSPプロジェクトについて
    2. TracのWikiページ
    3. リポジトリにコミットされるファイルについて
    4. チケットの登録ついて
    5. 質疑応答

開発の方針、ルールについて

ここでは、OpenHSPプロジェクトにおけるルールについて書いていきます。

OpenHSPプロジェクトについて

  • OpenHSPでは、次期バージョンとなるHSP本体、及び周辺ツールやドキュメントなどの開発をオープンに行なっています。
  • リポジトリのソースを変更(コミット)するためには、管理者(onitama)からユーザーIDの発行が必要になります。
  • プロジェクトに参加を希望する場合や、自分のソースを追加したい方は、OpenHSPトップページから管理者(onitama)までメールにてご連絡下さい。
  • HSPDev-MLでも、OpenHSPについての話題を取り扱っています。
  • Wikiページでの情報提供、ソースの差分提供はいつでも受け付けています。
  • Tracによるwebページ及びリポジトリは、独立したサーバーにて運用されています。不定期にメンテナンスを行なうことがありますのでご了承下さい。
  • 更新情報のメール配信には現在対応していません。今後サーバーの準備を進めていきたいと思います。

TracのWikiページ

  • Wikiページは基本的に誰でも編集可能です。
  • WikiページはOpenHSPで扱っているプロジェクトやソースコードに関する内容をまとめるためのものです。それ以外の内容は扱いません。
  • プロジェクトの各ディレクトリに対応したWikiページを用意しています。詳しい内容や注意事項は、そちらを参照してください。

リポジトリにコミットされるファイルについて

  • 不要なファイルはコミットしないようにしてください。中間ファイル(.objやVC++の設定ファイル等)は不要です。
  • コミットの際には、なるべくコメントを入れて変更点がわかるようにしておいてください。
  • 自分の管理外にあるディレクトリでのフォルダ作成、削除は管理人に確認してから行なってください。
  • 特に指定がない場合は基本的に日本語はsjis(Windows)コード、改行はCR/LF(Windows)で統一されています。
  • プラットフォーム依存するソースは、win32、linux等のディレクトリに分けています。

チケットの登録ついて

  • チケットは、このプロジェクトで扱うべき事項を管理するためのものです。要望や不具合の報告、与えられた作業を明確にすることができます。
  • チケットは、タスクの割り振りと、バグトラック、要望の集計などを兼ねたものです。
  • 新規のチケットは、チケット登録のページから作成することができます。
    • チケットの概要 … タイトルになります。チケットが示す内容を簡潔に書いて下さい。
    • チケットの分類 … そのチケットが「不具合(defect)」か「要望(enhancement)」か、または「必要な作業(task)」なのかを区分けします。
    • チケットについての完全な説明 … チケットの内容を簡潔に説明してください。挨拶や前置きは必要ありません。
    • 優先度 … 内容がどの程度重要かを示すものです。特に何もない限り「通常(major)」を指定してください。
    • コンポーネント … どのプラットフォームを対象にした内容かを示します。不明な場合や、すべてのプラットフォームが対象の場合は、「HSP(all)」を指定してください。
    • マイルストーン … 目標となるプロジェクトを指定します。特に該当がない場合は、「HSP3.2パッケージ」を指定してください。
    • バージョン … 対象となるバージョンを指定します。特に該当がない場合は、「3.2beta」を指定してください。
    • キーワード … 検索に必要なキーワードを指定します。特に指定しなくても構いません。
    • 関係者 … チケットに関係する人のリストを指定します。登録時は、特に指定しなくても構いません。
    • 担当者 … チケットが示す内容に責任を持つ人を指定します。管理者か、または本人が指定するので、登録時に入力する必要はありません。
    • 必要であれば、チケットの登録時にファイルを添付して下さい。
  • 不具合(defect)の登録は、OpenHSPが公開しているプロジェクトが対象になります。HSP3.1リリース版、及びHGIMG3の不具合は、HSPバグトラックにて受け付けています。
  • 「不具合(defect)」及び「要望(enhancement)」は、誰でも登録することが可能です。管理者(onitama)は、そのチケットが適切かどうかを判断し、該当する担当者へと送ります。
  • 担当者未定のチケットを担当したい場合は、管理者(onitama)までご連絡頂ければIDの発行も含めて対応致します。

質疑応答

  • 何か不明な点や、気づいたことがあれば、ここに追記、ツッコミを入れてください。
  • ソリューションとプロジェクトファイルの名前の付け方を統一したいと思います。規則としては、
    VC++ 2003用 ～_vc2003.vcproj, ～_vc2003.sln
    VC++ 2005用 ～_vc2005.vcproj, ～_vc2005.sln
    VC++ 2008用 ～_vc2008.vcproj, ～_vc2008.sln
    こんな感じで考えていますが、他によい命名規則はありますか？
    • これは、今後追加されるプロジェクトのことですか。それとも既存のすべての名前を変更ということでしょうか。
    • 既存のファイル修正は結構手間がかかると思いますが、行なって頂くぶんには問題ありません。
    • ファイル名だけでなくプロジェクト名まで変更すると、出力ファイル名が変わるのでそれは避けたいところです。
    • 個人的にはslnファイルは、それぞれのローカルで生成すればいい気がするので必要以上に用意しなくてもいいのでは。
      • .slnファイルは逆に自分は、複数のプロジェクトがまとまっていてリポジトリから取ってきてすぐに実行できるのであった方がよいと考えています。
        とはいえ今の所、複数のプロジェクトがまとまっている必要があるのはhsed3_footy2だけですが...
      • とりあえず複数プロジェクトが必要と思われる部分は.slnを置いてもらって構いません。
  • あと、こんな感じの提案などはどこで行うのがよいのでしょう？
    • win32プロジェクト共通のルールについては、hsp3ディレクトリでいいかと思います。