| 1 |
------------------------------------------------------------------------------ |
------------------------------------------------------------------------------ |
| 2 |
Project HOS 開発ポリシー（草案） |
Project HOS 開発ポリシー（草案） |
| 3 |
|
|
| 4 |
Copyright (C) 1998-2002 by Project HOS |
Copyright (C) 2002-2004 by Project HOS |
| 5 |
------------------------------------------------------------------------------ |
------------------------------------------------------------------------------ |
| 6 |
|
|
| 7 |
|
|
| 8 |
|
|
| 9 |
1. 目的 |
1. 概要 |
| 10 |
|
|
| 11 |
1.1 総則 |
本文書は Project HOS の活動における、開発ポリシーの総則です。 |
| 12 |
|
プロジェクト固有のポリシーは別途定めるものとしますが、各プロジェクトの |
| 13 |
|
開発ポリシーに記載の無い部分は暗黙的に本文書に従うものとします。 |
| 14 |
|
|
|
本プロジェクトは、誰もが自由に利用できる ITRON を開発することで、組み込み |
|
|
産業界及び、個人で楽しむ多くの方々に対して社会貢献を行うことと、メンバーの |
|
|
スキルアップを目的とします。 |
|
| 15 |
|
|
| 16 |
1.2 各人のポリシーの尊重 |
|
| 17 |
|
2. Project HOS について |
| 18 |
|
|
| 19 |
|
2.1. 概要 |
| 20 |
|
|
| 21 |
|
本プロジェクトは Hyper Operating System(以下 HOS と記載）を核とする、 |
| 22 |
|
組み込みソフトウェア開発者が有志で集い活動しているものです。 |
| 23 |
|
SourceForge.jp にて集団開発を行っていくにあたり、「Project HOS」との |
| 24 |
|
名称で、開発グループを結成いたしました。 |
| 25 |
|
プロジェクトの趣旨にご賛同いただける方は誰でも参加頂くことが可能です。 |
| 26 |
|
|
| 27 |
|
|
| 28 |
|
2.2. プロジェクトの目的 |
| 29 |
|
|
| 30 |
|
本プロジェクトは、誰もが自由に利用できる ITRON を開発することで、 |
| 31 |
|
組み込み産業界及び、個人で楽しむ多くの方々に対して社会貢献を行うことと、 |
| 32 |
|
メンバーのスキルアップを目的とします。 |
| 33 |
|
|
| 34 |
|
|
| 35 |
|
2.3. 各人のポリシーの尊重 |
| 36 |
|
|
| 37 |
オープン開発の性格上、いろいろな個人的ポリシーを持った方に参加いただく事に |
オープン開発の性格上、いろいろな個人的ポリシーを持った方に参加いただく事に |
| 38 |
なると思いますし、そうなって欲しいと願っております。 |
なると思いますし、そうなって欲しいと願っております。 |
| 39 |
それに際して、ポリシーの違いから議論が起こることも当然ありえると思います。 |
それに際して、ポリシーの違いから議論が起こることも当然ありえると思います。 |
| 40 |
技術者として、個人のポリシーと本分があるのは当然ですので、そのような場合は |
技術者として、個人のポリシーと本分があるのは当然ですので、そのような場合は |
| 41 |
是非有用な議論として発展させ、より良い形で全員にフィードバックされるよう |
是非有用な議論として発展させ、より良い形で全員にフィードバックされるよう |
| 42 |
各自お互いを尊重するよう心がけましょう。 |
各自お互いを尊重するよう心がけるものと致します。 |
| 43 |
|
|
| 44 |
|
|
| 45 |
|
3. 運用ルール |
| 46 |
|
|
| 47 |
|
3.1. ファイル名について |
| 48 |
|
|
| 49 |
|
本プロジェクトの開発の多くは、UNIX系、Windows系などクロスプラットフォーム |
| 50 |
|
をターゲットにしています。 |
| 51 |
|
従いまして、クロスプラットフォーム対応における問題回避のため最低限の |
| 52 |
|
ルールを定めます。 |
| 53 |
|
|
|
2. 技術的な決め事 |
|
| 54 |
|
|
| 55 |
2.1. ファイル名について |
3.2.1. 総則 |
| 56 |
|
|
| 57 |
2.1.1 総則 |
CVSからのチェックアウトを問題なく行うための最低限のルールとして、 |
| 58 |
|
以下のことを定めます。 |
| 59 |
|
|
|
UNIX系、Windows系両者の環境で利用できるようにファイル名は気をつけること |
|
|
とします。 |
|
|
以下の点に気をつけましょう。 |
|
|
|
|
| 60 |
・ファイル名に漢字(2byteコード）は利用しない |
・ファイル名に漢字(2byteコード）は利用しない |
| 61 |
・大文字小文字のみが異なるファイルは置かない |
・大文字小文字を区別出来ないファイルシステムで衝突が生じるファイル |
| 62 |
・環境依存のある文字は利用しない(Winの空白文字など) |
を同一ディレクトリに置かない(例: Makefileとmakefile) |
| 63 |
|
・環境依存のある文字は利用しない |
| 64 |
|
・空白文字も可能な限りファイル名に含めない |
| 65 |
|
|
| 66 |
|
|
| 67 |
2.1.2 C言語ソースの注意 |
3.2.2. DOS向けのファイル |
| 68 |
|
|
| 69 |
C言語プログラムのファイル名は、クロスプラットフォームを目的と |
MS-DOS用のツールに入力する可能性があるものに関してはさらに以下の |
| 70 |
するものに関しては 小文字のみの 8+3形式を標準とします。 |
るルールを定めます。 |
| 71 |
|
|
| 72 |
また、#include 命令で利用する際のファイル名も上記に順ずる事と |
・ファイル名は小文字に統一する |
| 73 |
します。Winでは大文字小文字は無視されるためコンパイルできるが、 |
・8+3形式に統一する |
|
Unixだと出来ないなどの問題を回避するためです。 |
|
| 74 |
|
|
| 75 |
|
|
| 76 |
2.1.3 その他のソース |
3.2.3. Windows向けのファイル |
|
原則、想定される環境に問題なく適用できればOKとします。 |
|
|
例えばUNIX専用や、Windows専用のツールを作る場合などは |
|
|
ある程度環境に特化した作りこみを許可します。 |
|
|
特に Java などは言語使用上、クラス名と同一のファイル名が必要で |
|
|
すし、C++などでもJava的にクラス名に合わせた命名とすべきと考えます。 |
|
|
この場合、言語仕様が当然優先します。 |
|
|
ただし、最低限別プラットフォームからのチェックアウトなど |
|
|
CVS操作で問題が出ない配慮だけは行ってください。 |
|
| 77 |
|
|
| 78 |
|
総則に反しない限り、Windows文化に合わせてよいものとします。 |
| 79 |
|
即ち、別環境でも最低限チェックアウトなどのCVS操作に支障を |
| 80 |
|
きたさない範囲とします。 |
| 81 |
|
|
|
2.2. 文字コードについて |
|
| 82 |
|
|
| 83 |
2.2.1 総則 |
3.2.4. UNIX系向けのファイル |
| 84 |
|
|
| 85 |
原則として、文字コードは EUC 改行コードは LFとします。 |
総則に反しない限り、UNIX文化に合わせてよいものとします。 |
| 86 |
Win環境では、適宜 SJIS + CR/FL に変換するなどして対応することと |
即ち、別環境でも最低限チェックアウトなどのCVS操作に支障を |
| 87 |
します。 |
きたさない範囲とします。 |
| 88 |
|
UNIX系の場合、実行可能属性などは適切に設定することとします。 |
| 89 |
|
|
|
2.2.2 例外 |
|
|
.bat、.dsw、.dsp など、Windows専用のファイルに関しては SJIS のまま |
|
|
とします。 |
|
| 90 |
|
|
| 91 |
2.2.3 履歴情報など |
3.2.5. ソースファイルからの参照について |
|
CVSの履歴情報入力など可能な限り、英文とします。 |
|
|
EUCコードで問題なく入力できることが確認できている環境からは |
|
|
日本語もOKとします。 |
|
|
おそらく、Windows環境からは EUC 入力は難しいと思います。 |
|
| 92 |
|
|
| 93 |
上記に伴い、Ryuzなどがお馬鹿な英語を入力する事が考えられますが、 |
例えば C言語の #include ディレクティブなど、ソース中で |
| 94 |
笑うのは心の中だけにしておきましょう (^^;; |
ファイル名を利用する場合、例えば、Windows環境で Sample.h |
| 95 |
|
を #include "sample.h" としてもエラーになりませんが、UNIX環境では |
| 96 |
|
大文字／小文字を区別するためファイルが見つからずコンパイル |
| 97 |
|
エラーとなります。 |
| 98 |
|
クロス環境で利用可能なソースについては、Windows環境でも |
| 99 |
|
気をつけて扱うよう心がけてください。 |
| 100 |
|
|
| 101 |
|
|
| 102 |
|
3.3. 文字コードについて |
| 103 |
|
|
| 104 |
2.2. バージョン名表記について |
3.3.1. 総則 |
| 105 |
|
|
| 106 |
2.2.1 総則 |
原則として CVS リポジトリに含めるテキストファイルは EUC |
| 107 |
考え中 |
文字コードとし、改行コードは LF のみとします。 |
| 108 |
|
Windows環境など、プラットフォームが EUC環境でない場合は、適宜 |
| 109 |
|
一括変換して扱うなどして対応することとします。 |
| 110 |
|
|
| 111 |
|
|
| 112 |
2.2.2 HOS-V4 のバージョン名 |
3.3.2. CVSのコミットログ |
| 113 |
|
|
| 114 |
HOS-V4 については、正式名 "Hyper Operating System V4"、略称 "HOS-V4" と |
CVSのコミットログなどのテキスト入力は可能な限り、英文とします。 |
| 115 |
します。 |
この場合、英語の苦手な方も居られると思いますので、どうしても |
| 116 |
よって、HOS-V4 Ver 0.01 をスタートとします。 |
うまく掛けない場合はローマ字表記なども許可とします。 |
| 117 |
V4 は μITRON 4.0 の 4 を表しますが、HOS-V4 においては固有名詞の一部で |
ただし、英語の得意な方などが、ローマ字を翻訳したり、文意の |
| 118 |
ありバージョンとは無関係と見なします。 |
誤りなど気がついた場合には、コミット実行者と連絡を取り、ログを |
| 119 |
小数部（下２桁）は、バグ修正や細かい機能追加などのマイナーバージョンを |
書き換えるなどの活動は制限しません（むしろ推奨いたします）。 |
|
表すものとし、整数部はメジャーバージョンを示すものとします。 |
|
| 120 |
|
|
|
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" へ |
|
|
向けた開発とは別線で枝が伸びるものとします。 |
|
| 121 |
|
|
| 122 |
|
|
| 123 |
|
4. CVS更新について |
| 124 |
|
|
| 125 |
3. 運用ルール |
4.1 総則 |
| 126 |
|
|
| 127 |
3.1 総則 |
原則として開発メンバーは HOS に有用と考えられる変更であれば |
| 128 |
|
他のメンバーの同意を必要とせずにトランク（開発レーン）に対して |
| 129 |
|
いつでも修正や機能追加を行う権限をもつものとします。 |
| 130 |
|
ただし、修正を行った場合はなるべく迅速に Developersフォーラムに |
| 131 |
|
修正内容を報告してください。 |
| 132 |
|
|
|
原則としてメンバーは HOS に有用と考えられる変更であれば他のメンバーの |
|
|
同意を必要とせずにを行っても良いこととします。 |
|
|
作業範囲及び影響波及範囲が狭い場合(１つのAPIに収まる程度など）は、 |
|
|
特にメンバーの同意を得ず行って構わないものとします。ただし、少なくとも |
|
|
コミット後の事後報告は行うようにしましょう。 |
|
|
影響範囲が大きいと考えられる場合は、作業開始時に Developes フォーラム |
|
|
に報告を入れてから着手してください。 |
|
|
問題があればコミットまでに他のメンバーから問い合わせが発生すると |
|
|
思います。 |
|
| 133 |
|
|
| 134 |
＜Ryuz 注記＞ |
4.2 修正作業手順 |
|
将来、ルールを変更する可能性もありますが、現時点では厳密なルールに |
|
|
よる明確な管理よりも、CVSなどに守られた体制を十分に活用してフット |
|
|
ワークを良くしたいと考えております |
|
|
なるべく変更にあたり少ない手順で誰でもいじれるようにしたいのですが |
|
|
いかがでしょうか？ |
|
| 135 |
|
|
| 136 |
|
作業範囲及び影響波及範囲が狭い場合(１つのAPIに収まる程度など）は、 |
| 137 |
|
特に予告無く行って構わないものとします。ただし、少なくともコミット後の |
| 138 |
|
事後報告は行うように心がけましょう。 |
| 139 |
|
影響範囲が大きいと考えられる場合は、作業開始時に Developers フォーラム |
| 140 |
|
に報告を入れてから着手してください。 |
| 141 |
|
問題があればコミットまでに他のメンバーから問い合わせが発生することが |
| 142 |
|
期待できます。 |
| 143 |
|
また、同バグ対応を複数人が作業してしまい、無駄な二重開発を回避する |
| 144 |
|
ことにもなります。 |
| 145 |
|
|
| 146 |
|
|
| 147 |
3.3.1 新規部分の開発 |
4.3.1 新規部分の開発 |
| 148 |
|
|
| 149 |
新規機能の開発に着手する場合は、事前に Developers フォーラムなどで |
新規機能の開発に着手する場合は、なるべく事前に Developers フォーラム |
| 150 |
他のメンバーに着手を宣言しましょう。 |
などで他のメンバーに着手を宣言しましょう（二重開発防止の為です）。 |
| 151 |
完成後は、ローカルの環境でテストし、問題なければCVSにコミットを掛け |
完成後は、ローカルの環境でテストし、問題なければCVSにコミットを掛け |
| 152 |
、フォーラムなどで完了を宣言しましょう。 |
、フォーラムなどで完了を宣言しましょう。 |
| 153 |
|
新規部分コミットの条件はプロジェクト毎に定めるものとします。 |
| 154 |
|
もし、変更規模や波及範囲が大きく、いきなりトランク（幹）にコミットを |
| 155 |
|
掛けるには危険と思われる場合は、管理者に連絡し、別途試験開発用の |
| 156 |
|
ブランチを作成してもらうなどの手続きが妥当な場合もありえます。 |
| 157 |
|
これは各プロジェクトのルールに従います。 |
| 158 |
|
|
| 159 |
|
|
| 160 |
3.3.2 既存ソースの機能変更 |
4.3.2 バグ修正 |
|
|
|
|
影響範囲が小さいと判断した場合は、ローカルでテスト後、コミットして |
|
|
からの事後報告で構いません。ただし、コミット時のメッセージには１行でも |
|
|
構いませんのでコメントをお願いします。 |
|
|
影響範囲がある程度あり、不安を感じる場合は、変更作業開始前にどの部分を |
|
|
どのように変更する予定か Developers フォーラムなどで他のメンバーに |
|
|
着手を宣言しましょう。 |
|
|
完了後、ローカルでテストし、問題なければCVSにコミットを掛け |
|
|
フォーラムで完了を宣言しましょう。 |
|
|
|
|
|
|
|
|
3.3.3 バグ修正 |
|
| 161 |
|
|
| 162 |
パッチやバグ報告がトラッキングにあがった場合、メンバーの誰であれ |
パッチやバグ報告がトラッキングにあがった場合、メンバーの誰であれ |
| 163 |
それに対応する権利を持ちます。 |
それに対応する権利を持ちます（もちろん義務はありません）。 |
| 164 |
自分で対処可能と判断した場合は、トラッキング情報の担当に自分の名前を |
対処頂く場合は、トラッキング情報の担当に自分の名前を設定し、 |
| 165 |
設定し、「解決」欄を accepted に変更してください。 |
「解決」欄を accepted に変更して、受け付けた旨を宣言してください。 |
| 166 |
これは、同一のバグに同時に複数人が対応してしまい時間をロスする |
これは、同一のバグに同時に複数人が対応してしまい時間をロスする |
| 167 |
ことを防ぐためです。 |
ことを防ぐためです。 |
| 168 |
対応にあたり、決めきれない部分がある場合は Developers フォーラム |
対応にあたり、決めきれない部分がある場合は Developers フォーラム |
| 169 |
にて対応策をみんなで議論しましょう。 |
にて対応策を議論しましょう。 |
|
|
|
| 170 |
修正が終わりましたら、トラッキング情報の「解決」欄を対応結果に |
修正が終わりましたら、トラッキング情報の「解決」欄を対応結果に |
| 171 |
応じて変更してください。 |
応じて変更してください。 |
| 172 |
また、必要と感じた場合は、対応終了を Developers フォーラムにも |
また、必要と感じた場合は、対応終了を Developers フォーラムにも |
| 173 |
報告いただければ助かります。 |
報告いただければ助かります。 |
| 174 |
|
|
| 175 |
|
メンバーがバグを発見した場合もまず、トラッキングのバグ報告に報告を |
| 176 |
|
上げる事とします。その場合そのまま自分を担当者としても構いませんし、 |
| 177 |
|
他のメンバーが名乗り出るのを待っていても構いません。 |
| 178 |
|
|
| 179 |
3.3.4 コミットにより問題が生じたら |
|
| 180 |
|
4.3.3 コミットにより問題が生じたら |
| 181 |
|
|
| 182 |
誰かが修正を加えてコミットしたことにより問題が生じたらどうしましょう。 |
誰かが修正を加えてコミットしたことにより問題が生じたらどうしましょう。 |
| 183 |
これは十分考えられます。例えば SH2 の環境でテストして問題ないと |
これは十分考えられます。例えば SH2 の環境でテストして問題ないと |
| 185 |
からです。 |
からです。 |
| 186 |
しかし焦る必要はありません。CVSは問題が生じる前のソースをいつでも |
しかし焦る必要はありません。CVSは問題が生じる前のソースをいつでも |
| 187 |
取り出せます。 |
取り出せます。 |
| 188 |
気づいた人は、まず簡単に修正できるかどうか判断を行ってください。 |
気づいた人は、まず簡単に修正できるかどうか（ご自分の時間的余裕など |
| 189 |
|
も含めて）判断を行ってください。 |
| 190 |
容易に修正可能であれば、修正後、CVSに修正内容を反映させてフォーラムに |
容易に修正可能であれば、修正後、CVSに修正内容を反映させてフォーラムに |
| 191 |
報告してください。 |
報告してください。 |
| 192 |
もし、修正が容易でなければ、その旨をフォーラムに挙げて下さい。 |
もし、修正が容易でなければ、その旨をトラッキングのバグ報告に |
| 193 |
修正を取り消して前のバージョンに戻すのか、そのままさらに修正して |
上げて下さい。 |
| 194 |
問題を解決するのか、判断が必要となります。 |
|
| 195 |
|
場合によっては修正を取り消して前のバージョンに戻すのか、そのまま |
| 196 |
|
さらに修正して問題を解決するのか、判断が必要となる場合があります。 |
| 197 |
個人で判断しかねる場合は、必要に応じて議論を行いましょう。 |
個人で判断しかねる場合は、必要に応じて議論を行いましょう。 |
| 198 |
|
|
| 199 |
何れにしろ、問題が解決するまでは、他の人は正常に動作していた |
何れにしろ、問題が解決するまでは、他の人は正常に動作していた |
| 202 |
|
|
| 203 |
|
|
| 204 |
------------------------------------------------------------------------------ |
------------------------------------------------------------------------------ |
| 205 |
Copyright (C) 1998-2002 by Project HOS |
Copyright (C) 2002-2004 by Project HOS |
| 206 |
------------------------------------------------------------------------------ |
------------------------------------------------------------------------------ |
Parent Directory
Revision Log
Revision Graph
Patch