hos/policy/policy.txt

------------------------------------------------------------------------------
 Project HOS 開発ポリシー（草案）                                             
                                                                              
                                            Copyright (C) 2002 by Project HOS 
------------------------------------------------------------------------------


1. 概要

  本文書はは Project HOS の活動における、開発ポリシーの総則です。
  プロジェクト固有のポリシーは別途定めるものとしますが、各プロジェクトの
開発ポリシーに記載の無い部分は暗黙的に本文書に従うものとします。


2. Project HOS について

2.1. 概要

  本プロジェクトは Hyper Operating System(以下 HOS と記載）を核とする、
組み込みソフトウェア開発者が有志で集い活動しているものです。
  SourceForge.jp にて集団開発を行っていくにあたり、「Project HOS」との
名称で、開発グループを結成いたしました。
  プロジェクトの趣旨にご賛同いただける方は誰でも参加頂くことが可能です。


2.2. プロジェクトの目的

  本プロジェクトは、誰もが自由に利用できる ITRON を開発することで、
組み込み産業界及び、個人で楽しむ多くの方々に対して社会貢献を行うことと、
メンバーのスキルアップを目的とします。


2.3. 各人のポリシーの尊重

  オープン開発の性格上、いろいろな個人的ポリシーを持った方に参加いただく事に
なると思いますし、そうなって欲しいと願っております。
  それに際して、ポリシーの違いから議論が起こることも当然ありえると思います。
  技術者として、個人のポリシーと本分があるのは当然ですので、そのような場合は
是非有用な議論として発展させ、より良い形で全員にフィードバックされるよう
各自お互いを尊重するよう心がるものと致します。


2. 運用ルール

2.1. ファイル名について

  本プロジェクトの開発の多くは、UNIX系、Windows系などクロスプラットフォーム
をターゲットにしています。
  従いまして、クロスプラットフォーム対応における問題回避のため最低限の
るルールを定めます。


2.2.1. 総則

  CVSからのチェックアウトを問題なく行うために最低限以下のことを定めます。

  ・ファイル名に漢字(2byteコード）は利用しない
  ・大文字小文字のみが異なるファイルは置かない
  ・環境依存のある文字は利用しない
  ・空白文字も可能な限りファイル名に含めない


2.2.2. DOS向けのファイル

  MS-DOS用のツールに入力する可能性があるものに関してはさらに以下の
るルールを定めます。

  ・ファイル名は小文字に統一する
  ・8+3形式に統一する


2.2.3. Windows向けのファイル

  総則に反しない限り、Windows文化に合わせてよいものとします。
  即ち、別環境でも最低限チェックアウトなどのCVS操作に支障を
きたさない範囲とします。


2.2.4. UNIX系向けのファイル

  総則に反しない限り、UNIX文化に合わせてよいものとする。
  即ち、別環境でも最低限チェックアウトなどのCVS操作に支障を
きたさない範囲とします。
  UNIX系の場合、実行可能属性などは適切に設定することとします。


2.2.5. ソースファイルからの参照について

  例えば C言語の #include ディレクティブなど、ソース中で
ファイル名を利用する場合、例えば、Windows環境で Sample.h
を #include "sample.h" としてもエラーになりませんが、UNIX環境では
大文字／小文字を区別するためファイルが見つからずコンパイル
エラーとなります。
  クロス環境で利用可能なソースについては、Windows環境でも
気をつけて扱うよう心がけてください。


2.3. 文字コードについて

2.3.1. 総則

  原則として CVS リポジトリに含めるテキストファイルは EUC
文字コードとし、改行コードは LF のみとします。
  Windows環境など、プラットフォームが EUC環境でない場合は、適宜
一括変換して扱うなどして対応することとします。


2.3.2. CVSのコミットログ

  CVSのコミットログなどのテキスト入力は可能な限り、英文とします。
  この場合、英語の苦手な方も居られると思いますので、どうしても
うまく掛けない場合はローマ字表記なども許可とします。
  ただし、英語の得意な方などが、ローマ字を翻訳したり、文意の
誤りなど気がついた場合には、コミット実行者と連絡を取り、ログを
書き換えるなどの活動は制限しません（むしろ推奨いたします）。


2.4. CVS更新について

3.1 総則

  原則として開発メンバーは HOS に有用と考えられる変更であれば
他のメンバーの同意を必要とせずにトランク（開発レーン）に対して
いつでも修正や機能追加を行う権限をもつものとします。
  ただし、修正を行った場合はなるべく迅速に Developersフォーラムに
修正内容を報告してください。


3.2 修正作業手順

  作業範囲及び影響波及範囲が狭い場合(１つのAPIに収まる程度など）は、
特に予告無く行って構わないものとします。ただし、少なくともコミット後の
事後報告は行うように心がけましょう。
  影響範囲が大きいと考えられる場合は、作業開始時に Developes フォーラム
に報告を入れてから着手してください。
  問題があればコミットまでに他のメンバーから問い合わせが発生することが
期待できます。
  また、同バグ対応を複数人が作業してしまい、無駄な二重開発を回避する
ことにもなります。


3.3.1 新規部分の開発

  新規機能の開発に着手する場合は、事前に Developers フォーラムなどで
他のメンバーに着手を宣言しましょう。
  完成後は、ローカルの環境でテストし、問題なければCVSにコミットを掛け
、フォーラムなどで完了を宣言しましょう。


3.3.3 バグ修正

  パッチやバグ報告がトラッキングにあがった場合、メンバーの誰であれ
それに対応する権利を持ちます（もちろん義務はありません）。
  対処頂く場合は、トラッキング情報の担当に自分の名前を設定し、
「解決」欄を accepted に変更して、受け付けた旨を宣言してください。
  これは、同一のバグに同時に複数人が対応してしまい時間をロスする
ことを防ぐためです。
  対応にあたり、決めきれない部分がある場合は Developers フォーラム
にて対応策を議論しましょう。
  修正が終わりましたら、トラッキング情報の「解決」欄を対応結果に
応じて変更してください。
  また、必要と感じた場合は、対応終了を Developers フォーラムにも
報告いただければ助かります。

  メンバーがバグを発見した場合もまず、トラッキングのバグ報告に報告を
上げる事とします。その場合そのまま自分を担当者としても構いませんし、
他のメンバーが名乗り出るのを待っていても構いません。


3.3.4 コミットにより問題が生じたら

  誰かが修正を加えてコミットしたことにより問題が生じたらどうしましょう。
  これは十分考えられます。例えば SH2 の環境でテストして問題ないと
判断して、コミットしたところ、H8環境で問題が出る可能性などありえる
からです。
  しかし焦る必要はありません。CVSは問題が生じる前のソースをいつでも
取り出せます。
  気づいた人は、まず簡単に修正できるかどうか（ご自分の時間的余裕など
も含めて）判断を行ってください。
  容易に修正可能であれば、修正後、CVSに修正内容を反映させてフォーラムに
報告してください。
  もし、修正が容易でなければ、その旨をトラッキングのバグ報告に
上げて下さい。

  場合によっては修正を取り消して前のバージョンに戻すのか、そのまま
さらに修正して問題を解決するのか、判断が必要となる場合があります。
  個人で判断しかねる場合は、必要に応じて議論を行いましょう。

  何れにしろ、問題が解決するまでは、他の人は正常に動作していた
バージョンを取り出して現在の作業を続行させることが可能です。


------------------------------------------------------------------------------
 Copyright (C) 2002 by Project HOS                                            
------------------------------------------------------------------------------