1998/10/27
	招布、任天堂双方のソースツリー管理に関連する役割について


					任天堂株式会社 開発３部 橋田貴之

1. はじめに(ソースツリーの基礎知識)


ソースツリー：
	N64 に関連するソースを階層的にまとめたもの。

CVS:
	ソースツリーの変更履歴(世代)を管理するために、開発３部で使用し
	ている GNU のツール。RCS という UNIX 標準の履歴管理ツールをベー
	スにしている。３部で使用している CVS のバージョンは 1.8.1

リビジョン：
	CVS では、ソースをファイル単位で番号をふって管理している。その
	番号が「リビジョン番号」。原則として、1.1, 1.2, ..., 1.9,
	1.10, 1.11, .... というように番号が増えていく。

マスターソースツリー：
	ソースツリーの過去の全ての変更履歴を含むもの。CVS で管理する形
	式になっているため、コンパイルは不可能。CVS のコマンドを使って、
	ここからどのファイルの好きなリビジョンをとってくることができる。
	今後は、開発３部、業務部、招布の３つの部署・会社でマスターを持
	つことになるが、このうち特に招布が所有するものを「オリジナルの
	マスター」、それ以外のものを「マスターのコピー」ということにす
	る。これら３つのマスターは、同期を取った直後は同じものだが、そ
	れ以降、次に同期を取るまでは「コピー」といえども、招布の「オリ
	ジナル」と全く同じものとは限らない。
	ソースツリーは、このマスターソースツリーから、CVS のコマンドを
	用いて(普通は最新のものを)持ってきたものである。
	
ローカルソースツリー：
	マスターは各部署が１つずつ所有するが、そのマスターから取得した
	ソースツリーは、作業する人それぞれが、それぞれのマシン上で持つ
	ことになる。そのソースツリーを「ローカルソースツリー」という。
	コンパイルが可能。

タグ：
	CVS はファイルごとにリビジョンを管理するため、ある時点の状態に
	ソースツリーを戻そうとした場合、そのときにどのファイルがどのリ
	ビジョン番号だったかを記録しておかなければいけない。そのときに
	使用するのがタグで、例えば 2.0I リリース時には OS_V2_0I という
	タグを振った。つまり、OS_V2_0I というタグを用いると、全てのファ
	イルを、2.0I リリース時の状態に戻すことができる。



2. それぞれの部署もしくは会社の役割について


マスターソースのオリジナルは招布が持ち、業務と開発３部はそのコピーを所
有する。


	　　　開発３部
	　　　　↑｜
	　　　　｜｜
	　　転送｜｜変更
	　　　　｜｜
	　　　　｜↓
	　　　 業務部
	　　　　↑｜
	　　　　｜｜
	　　変更｜｜転送
	　　　　｜｜
	　　　　｜↓
	　　　　招布


ただし、３部や招布は、変更しても、直後に業務部に送付するわけではないこ
とに注意。詳しくは「4.リリース」を参照。


以下は、各部署もしくは会社の役割(カッコ内は責任者、敬称略、暫定)


招布(道関)：マスターの保守。招布担当のディレクトリに関しては、招布が自
	由に変更して良い。リリース時のパッケージング、確認。

業務(作野)：開発３部から受け取ったソースツリーを招布へ、招布から受け取っ
	たソースツリーを開発３部に転送する。パッチなどのリリースの号令
	をかける。リリース時の確認、発送作業。

開発３部(橋田)：３部担当の部分の変更をする。リリース時は３部変更分の確
	認作業。


＊変更するのは、原則として招布と３部のみ。

＊使用する CVS のバージョンは必ず 1.8.1 とする。CVS のバージョンアップ
をする際には、必ず２部署１会社で相談の上、同時にするようにする。



3. 連絡、配布

責任者同士の連絡や質問、相談等は、必ず業務部の責任者にも cc でメールを
出す等、連絡がいくようにする。

各部署・会社の責任者ではない人が、責任者を通さずに外部の人と質問、依頼、
指示、相談等をしてはならない。必ず各部署の責任者同士でまずは連絡をつけ
ることとする。

マスターの配布に関しては、「2. それぞれの部署もしくは会社の役割につい
て」のところにかいてある図の道筋でしかやり取りをしない。つまり、例えば
３部が直接招布にマスターを配布することはしない。



4. リリース

リリースはメジャーリリースとパッチリリースの２つのタイプがある。

＜以下、要相談事項＞
メジャーリリースは、例えば６ヶ月に一回等、定期的にリリースするものとす
る。
パッチリリースは、致命的なバグ等、どうしても定期のメジャーリリースが待
てない場合に緊急で出すものとする。その際、緊急で出すもの以外の細かい変
更は、定期リリースまで待つものとする(ついでのリリースはしない)。

３部および招布はバグを発見または修正したときに、それが致命的または緊急
を要すると判断した場合は、すぐに業務部へ連絡する。

＜ここまで＞


リリース時に、３つのマスターの同期を取る。原則として、これ以外のタイミ
ングでの同期は取らない。


	リリースの流れ：

	i)   メジャーリリースの時期が来たら、業務部がスケジュールを立
	     て、招布と３部に連絡をする。
	     パッチの場合は、そのパッチの動機となったバグの修正が完了
	     した時点で、業務部がやはりスケジュールを立てて、招布と３
	     部に連絡をする。
	ii)  ３部は３部変更分のマスターおよび変更ログを業務部に送付。
	     業務部はそれを招布に送付。
	iii) 招布は３部からのマスターを受け取ったのち、招布のものと融
	     合させ、評価版をパッケージングする。
	iv)  評価版は業務部を通じて３部に配布される。
	v)   ３部は３部が変更した部分の動作確認をする。業務部と招布は
	     全体的なチェックを行なう。
	vi)  業務部は３部・招布の報告をもとに評価版の是非を判断、招布
	     および３部に通知する。
	vii) 業務は是とした評価版を正式版とし、ライセンシーに配布。
	viii)招布は、正式版を作成した時点のソースツリーにタグを振り、
	     業務部を通じて３部にマスターおよび変更ログ(３部の分と招布
	     の分)を配布。


その他、必要に応じて担当者相談の上、同期を取ることもあるかもしれない。



5. 変更ログ

ソースを改変する開発３部および招布は、必ず変更した際に、CVS のログとは
別に変更ログを残しておく。リリースの際は、そのログをまとめて業務部に提
出すること。



6. ソースのライセンシー等への配布について

ソースのライセンシーやツールメーカーへの配布に関しては、すでに３部と業
務部との間で話しあわれたことを踏まえて、業務部の判断および管理下で行わ
れる。

配布時は、マスターを配布してはならない。


7. その他
「ソースツリーにおける各ディレクトリの管理分担」については別紙を参照する
こと。