| 1 |
------------------------------------------------------------------------------ |
| 2 |
Project HOS 開発ポリシー（草案） |
| 3 |
|
| 4 |
Copyright (C) 2002-2004 by Project HOS |
| 5 |
------------------------------------------------------------------------------ |
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
1. 概要 |
| 10 |
|
| 11 |
本文書は Project HOS の活動における、開発ポリシーの総則です。 |
| 12 |
プロジェクト固有のポリシーは別途定めるものとしますが、各プロジェクトの |
| 13 |
開発ポリシーに記載の無い部分は暗黙的に本文書に従うものとします。 |
| 14 |
|
| 15 |
|
| 16 |
|
| 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 |
|
| 54 |
|
| 55 |
3.2.1. 総則 |
| 56 |
|
| 57 |
CVSからのチェックアウトを問題なく行うための最低限のルールとして、 |
| 58 |
以下のことを定めます。 |
| 59 |
|
| 60 |
・ファイル名に漢字(2byteコード）は利用しない |
| 61 |
・大文字小文字を区別出来ないファイルシステムで衝突が生じるファイル |
| 62 |
を同一ディレクトリに置かない(例: Makefileとmakefile) |
| 63 |
・環境依存のある文字は利用しない |
| 64 |
・空白文字も可能な限りファイル名に含めない |
| 65 |
|
| 66 |
|
| 67 |
3.2.2. DOS向けのファイル |
| 68 |
|
| 69 |
MS-DOS用のツールに入力する可能性があるものに関してはさらに以下の |
| 70 |
るルールを定めます。 |
| 71 |
|
| 72 |
・ファイル名は小文字に統一する |
| 73 |
・8+3形式に統一する |
| 74 |
|
| 75 |
|
| 76 |
3.2.3. Windows向けのファイル |
| 77 |
|
| 78 |
総則に反しない限り、Windows文化に合わせてよいものとします。 |
| 79 |
即ち、別環境でも最低限チェックアウトなどのCVS操作に支障を |
| 80 |
きたさない範囲とします。 |
| 81 |
|
| 82 |
|
| 83 |
3.2.4. UNIX系向けのファイル |
| 84 |
|
| 85 |
総則に反しない限り、UNIX文化に合わせてよいものとします。 |
| 86 |
即ち、別環境でも最低限チェックアウトなどのCVS操作に支障を |
| 87 |
きたさない範囲とします。 |
| 88 |
UNIX系の場合、実行可能属性などは適切に設定することとします。 |
| 89 |
|
| 90 |
|
| 91 |
3.2.5. ソースファイルからの参照について |
| 92 |
|
| 93 |
例えば C言語の #include ディレクティブなど、ソース中で |
| 94 |
ファイル名を利用する場合、例えば、Windows環境で Sample.h |
| 95 |
を #include "sample.h" としてもエラーになりませんが、UNIX環境では |
| 96 |
大文字／小文字を区別するためファイルが見つからずコンパイル |
| 97 |
エラーとなります。 |
| 98 |
クロス環境で利用可能なソースについては、Windows環境でも |
| 99 |
気をつけて扱うよう心がけてください。 |
| 100 |
|
| 101 |
|
| 102 |
3.3. 文字コードについて |
| 103 |
|
| 104 |
3.3.1. 総則 |
| 105 |
|
| 106 |
原則として CVS リポジトリに含めるテキストファイルは EUC |
| 107 |
文字コードとし、改行コードは LF のみとします。 |
| 108 |
Windows環境など、プラットフォームが EUC環境でない場合は、適宜 |
| 109 |
一括変換して扱うなどして対応することとします。 |
| 110 |
|
| 111 |
|
| 112 |
3.3.2. CVSのコミットログ |
| 113 |
|
| 114 |
CVSのコミットログなどのテキスト入力は可能な限り、英文とします。 |
| 115 |
この場合、英語の苦手な方も居られると思いますので、どうしても |
| 116 |
うまく掛けない場合はローマ字表記なども許可とします。 |
| 117 |
ただし、英語の得意な方などが、ローマ字を翻訳したり、文意の |
| 118 |
誤りなど気がついた場合には、コミット実行者と連絡を取り、ログを |
| 119 |
書き換えるなどの活動は制限しません（むしろ推奨いたします）。 |
| 120 |
|
| 121 |
|
| 122 |
|
| 123 |
4. CVS更新について |
| 124 |
|
| 125 |
4.1 総則 |
| 126 |
|
| 127 |
原則として開発メンバーは HOS に有用と考えられる変更であれば |
| 128 |
他のメンバーの同意を必要とせずにトランク（開発レーン）に対して |
| 129 |
いつでも修正や機能追加を行う権限をもつものとします。 |
| 130 |
ただし、修正を行った場合はなるべく迅速に Developersフォーラムに |
| 131 |
修正内容を報告してください。 |
| 132 |
|
| 133 |
|
| 134 |
4.2 修正作業手順 |
| 135 |
|
| 136 |
作業範囲及び影響波及範囲が狭い場合(１つのAPIに収まる程度など）は、 |
| 137 |
特に予告無く行って構わないものとします。ただし、少なくともコミット後の |
| 138 |
事後報告は行うように心がけましょう。 |
| 139 |
影響範囲が大きいと考えられる場合は、作業開始時に Developers フォーラム |
| 140 |
に報告を入れてから着手してください。 |
| 141 |
問題があればコミットまでに他のメンバーから問い合わせが発生することが |
| 142 |
期待できます。 |
| 143 |
また、同バグ対応を複数人が作業してしまい、無駄な二重開発を回避する |
| 144 |
ことにもなります。 |
| 145 |
|
| 146 |
|
| 147 |
4.3.1 新規部分の開発 |
| 148 |
|
| 149 |
新規機能の開発に着手する場合は、なるべく事前に Developers フォーラム |
| 150 |
などで他のメンバーに着手を宣言しましょう（二重開発防止の為です）。 |
| 151 |
完成後は、ローカルの環境でテストし、問題なければCVSにコミットを掛け |
| 152 |
、フォーラムなどで完了を宣言しましょう。 |
| 153 |
新規部分コミットの条件はプロジェクト毎に定めるものとします。 |
| 154 |
もし、変更規模や波及範囲が大きく、いきなりトランク（幹）にコミットを |
| 155 |
掛けるには危険と思われる場合は、管理者に連絡し、別途試験開発用の |
| 156 |
ブランチを作成してもらうなどの手続きが妥当な場合もありえます。 |
| 157 |
これは各プロジェクトのルールに従います。 |
| 158 |
|
| 159 |
|
| 160 |
4.3.2 バグ修正 |
| 161 |
|
| 162 |
パッチやバグ報告がトラッキングにあがった場合、メンバーの誰であれ |
| 163 |
それに対応する権利を持ちます（もちろん義務はありません）。 |
| 164 |
対処頂く場合は、トラッキング情報の担当に自分の名前を設定し、 |
| 165 |
「解決」欄を accepted に変更して、受け付けた旨を宣言してください。 |
| 166 |
これは、同一のバグに同時に複数人が対応してしまい時間をロスする |
| 167 |
ことを防ぐためです。 |
| 168 |
対応にあたり、決めきれない部分がある場合は Developers フォーラム |
| 169 |
にて対応策を議論しましょう。 |
| 170 |
修正が終わりましたら、トラッキング情報の「解決」欄を対応結果に |
| 171 |
応じて変更してください。 |
| 172 |
また、必要と感じた場合は、対応終了を Developers フォーラムにも |
| 173 |
報告いただければ助かります。 |
| 174 |
|
| 175 |
メンバーがバグを発見した場合もまず、トラッキングのバグ報告に報告を |
| 176 |
上げる事とします。その場合そのまま自分を担当者としても構いませんし、 |
| 177 |
他のメンバーが名乗り出るのを待っていても構いません。 |
| 178 |
|
| 179 |
|
| 180 |
4.3.3 コミットにより問題が生じたら |
| 181 |
|
| 182 |
誰かが修正を加えてコミットしたことにより問題が生じたらどうしましょう。 |
| 183 |
これは十分考えられます。例えば SH2 の環境でテストして問題ないと |
| 184 |
判断して、コミットしたところ、H8環境で問題が出る可能性などありえる |
| 185 |
からです。 |
| 186 |
しかし焦る必要はありません。CVSは問題が生じる前のソースをいつでも |
| 187 |
取り出せます。 |
| 188 |
気づいた人は、まず簡単に修正できるかどうか（ご自分の時間的余裕など |
| 189 |
も含めて）判断を行ってください。 |
| 190 |
容易に修正可能であれば、修正後、CVSに修正内容を反映させてフォーラムに |
| 191 |
報告してください。 |
| 192 |
もし、修正が容易でなければ、その旨をトラッキングのバグ報告に |
| 193 |
上げて下さい。 |
| 194 |
|
| 195 |
場合によっては修正を取り消して前のバージョンに戻すのか、そのまま |
| 196 |
さらに修正して問題を解決するのか、判断が必要となる場合があります。 |
| 197 |
個人で判断しかねる場合は、必要に応じて議論を行いましょう。 |
| 198 |
|
| 199 |
何れにしろ、問題が解決するまでは、他の人は正常に動作していた |
| 200 |
バージョンを取り出して現在の作業を続行させることが可能です。 |
| 201 |
|
| 202 |
|
| 203 |
|
| 204 |
------------------------------------------------------------------------------ |
| 205 |
Copyright (C) 2002-2004 by Project HOS |
| 206 |
------------------------------------------------------------------------------ |
Parent Directory
Revision Log
Revision Graph