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