hos/policy/policy.txt

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


1. 目的

1.1 総則

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

1.2 各人のポリシーの尊重

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


2. 技術的な決め事

2.1. ファイル名について

2.1.1 総則

  UNIX系、Windows系両者の環境で利用できるようにファイル名は気をつけること
とします。
  以下の点に気をつけましょう。
  
  ・ファイル名に漢字(2byteコード）は利用しない
  ・大文字小文字のみが異なるファイルは置かない
  ・環境依存のある文字は利用しない(Winの空白文字など)


2.1.2 C言語ソースの注意

  C言語プログラムのファイル名は、クロスプラットフォームを目的と
するものに関しては 小文字のみの 8+3形式を標準とします。

  また、#include 命令で利用する際のファイル名も上記に順ずる事と
します。Winでは大文字小文字は無視されるためコンパイルできるが、
Unixだと出来ないなどの問題を回避するためです。


2.1.3 その他のソース
  原則、想定される環境に問題なく適用できればOKとします。
例えばUNIX専用や、Windows専用のツールを作る場合などは
ある程度環境に特化した作りこみを許可します。
  特に Java などは言語使用上、クラス名と同一のファイル名が必要で
すし、C++などでもJava的にクラス名に合わせた命名とすべきと考えます。
  この場合、言語仕様が当然優先します。
  ただし、最低限別プラットフォームからのチェックアウトなど
CVS操作で問題が出ない配慮だけは行ってください。


2.2. 文字コードについて

2.2.1 総則

  原則として、文字コードは EUC 改行コードは LFとします。
  Win環境では、適宜 SJIS + CR/FL に変換するなどして対応することと
します。

2.2.2 例外
  .bat、.dsw、.dsp など、Windows専用のファイルに関しては SJIS のまま
とします。

2.2.3 履歴情報など
  CVSの履歴情報入力など可能な限り、英文とします。
  EUCコードで問題なく入力できることが確認できている環境からは
日本語もOKとします。
  おそらく、Windows環境からは EUC 入力は難しいと思います。

  上記に伴い、Ryuzなどがお馬鹿な英語を入力する事が考えられますが、
笑うのは心の中だけにしておきましょう (^^;;


2.2. バージョン名表記について

2.2.1 総則
  考え中


2.2.2 HOS-V4 のバージョン名

  HOS-V4 については、正式名 "Hyper Operating System V4"、略称 "HOS-V4" と
します。
  よって、HOS-V4 Ver 0.01 をスタートとします。
  V4 は μITRON 4.0 の 4 を表しますが、HOS-V4 においては固有名詞の一部で
ありバージョンとは無関係と見なします。
  小数部（下２桁）は、バグ修正や細かい機能追加などのマイナーバージョンを
表すものとし、整数部はメジャーバージョンを示すものとします。

  SF.jp 以降以前のものは 「開発スナップショット 2002/06/30 版」を表記上の
名称として扱い、CVS内のタグは ss_2002-06-30 のように ss_yyyy-mm-dd として
扱うこととします。
  また、SF.jp 以降後の開発については、ver0_01 のようにバージョン番号で
管理いたします。
  もし、過去バージョンを分岐して（枝を作って）リリースが必要な場合は、
ver0_01_branch1 のようにブランチタグを打ち、リリース時は ver0_01_r1
のようにリリース番号を付けるものとします。
  その場合、リリース名称は "Ver 0.01 Rel.1" となり、これは "Ver 0.02" へ
向けた開発とは別線で枝が伸びるものとします。


3. 運用ルール

3.1 総則

  原則としてメンバーは HOS に有用と考えられる変更であれば他のメンバーの
同意を必要とせずにを行っても良いこととします。
  作業範囲及び影響波及範囲が狭い場合(１つのAPIに収まる程度など）は、
特にメンバーの同意を得ず行って構わないものとします。ただし、少なくとも
コミット後の事後報告は行うようにしましょう。
  影響範囲が大きいと考えられる場合は、作業開始時に Developes フォーラム
に報告を入れてから着手してください。
  問題があればコミットまでに他のメンバーから問い合わせが発生すると
思います。

＜Ryuz 注記＞
  将来、ルールを変更する可能性もありますが、現時点では厳密なルールに
よる明確な管理よりも、CVSなどに守られた体制を十分に活用してフット
ワークを良くしたいと考えております
  なるべく変更にあたり少ない手順で誰でもいじれるようにしたいのですが
いかがでしょうか？


3.3.1 新規部分の開発

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


3.3.2 既存ソースの機能変更

  影響範囲が小さいと判断した場合は、ローカルでテスト後、コミットして
からの事後報告で構いません。ただし、コミット時のメッセージには１行でも
構いませんのでコメントをお願いします。
  影響範囲がある程度あり、不安を感じる場合は、変更作業開始前にどの部分を
どのように変更する予定か Developers フォーラムなどで他のメンバーに
着手を宣言しましょう。
  完了後、ローカルでテストし、問題なければCVSにコミットを掛け
フォーラムで完了を宣言しましょう。


3.3.3 バグ修正

  パッチやバグ報告がトラッキングにあがった場合、メンバーの誰であれ
それに対応する権利を持ちます。
  自分で対処可能と判断した場合は、トラッキング情報の担当に自分の名前を
設定し、「解決」欄を accepted に変更してください。
  これは、同一のバグに同時に複数人が対応してしまい時間をロスする
ことを防ぐためです。
  対応にあたり、決めきれない部分がある場合は Developers フォーラム
にて対応策をみんなで議論しましょう。

  修正が終わりましたら、トラッキング情報の「解決」欄を対応結果に
応じて変更してください。
  また、必要と感じた場合は、対応終了を Developers フォーラムにも
報告いただければ助かります。


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

  誰かが修正を加えてコミットしたことにより問題が生じたらどうしましょう。
  これは十分考えられます。例えば SH2 の環境でテストして問題ないと
判断して、コミットしたところ、H8環境で問題が出る可能性などありえる
からです。
  しかし焦る必要はありません。CVSは問題が生じる前のソースをいつでも
取り出せます。
  気づいた人は、まず簡単に修正できるかどうか判断を行ってください。
  容易に修正可能であれば、修正後、CVSに修正内容を反映させてフォーラムに
報告してください。
  もし、修正が容易でなければ、その旨をフォーラムに挙げて下さい。
  修正を取り消して前のバージョンに戻すのか、そのままさらに修正して
問題を解決するのか、判断が必要となります。
  個人で判断しかねる場合は、必要に応じて議論を行いましょう。

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


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