path: root/ja_JP.EUC/handbook/policies.sgml

<!-- $Id: policies.sgml,v 1.1.1.1 1996-11-15 05:14:44 asami Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.5 -->

<chapt><heading>ソースツリーのガイドラインおよび方針
<label id="policies">
</heading>

<p><em>原作: &a.phk;</em><newline>.
<p><em>訳者: &a.mihoko;<newline>
6 September 1996 </em>.

本章は、FreeBSD のソースツリーについてのさまざまなガイドラインやポリ
シーについて書かれています。

<sect><heading>Makefile 中の MAINTAINER
<label id="policies:maintainer">
</heading>

<p>1996年6月。

<p>FreeBSD 配布物の特定の部分が、一人の人やグループによって保守
されている場合は、ソースツリーの当該 Makefile に

<verb>
	MAINTAINER= email-addresses
</verb>

<p>が付け加えられています。これを記述することによって、この部分が誰
に保守管理されているかを世界中のユーザに伝えることができます。 

<p>この意味は次のとおりです:

<p>保守担当者がそのコードを所有し、そのコードに対する責任を持っ
ています。すなわち、その人がそのコードに関するバグ吸収やトラブル報告
に対する回答をします。また、そのコードが寄贈ソフトウェアの場合には、
そのソフトウェアの新しいバージョンに適切に追従していきます。 

<p>保守担当者が決められているディレクトリに対して変更をおこなう場合は、
変更をおこなう前に、その変更内容を保守担当者に送って、
保守担当者にレビューをしてもらってください。
保守担当者が、電子メールに一定期間応答しない場合にのみ、
保守担当者がレビューすることなしに、変更をおこなうことが認められます。
しかしながら、そのような場合でも可能な限り、変更点を第三者にレビュー
してもらうようにしてください。

<p>もちろん、この義務を引き受けることができない人やグループを保守管
理者として追加することはできません。
また、保守管理者がソースツリー管理者 ("committer") である必要は
ありません。

<sect><heading>寄贈ソフトウェア</heading>

<p>1996年6月。

<p>FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト
以外のところで保守されています。
歴史的な経緯から、私たちはこれを <em> 寄贈 </em> ソフトウェアと呼
んでいます。perl や gcc, patch などがその例です。

<p>ここ数年来、この種のソフトウェアの取り扱いには、さまざまな方法が取ら
れてきましたが、どの方法にもいくつかの利点と欠点があります。
これまで欠点のない明確な方法はありませんでした。

<p>
議論した結果、これらの方法のうちの一つが「公式な」方法として選択され
ました。その方法が、今後、この種のソフトウェアを取り込む場合に、使用
されます。
その上、この方法では、だれもが(cvs にアクセス権のない人でさえ)「公式」
バージョンのソースに対する差分を簡単に得ることができます。
これは古い方法にはなかった大きな利点です。ですから、
既存の寄贈ソフトウェアも、この方法に収束していくことを強く望んでいます。
この方法を使用することにより、寄贈ソフトウェアの主な開発者に、変更
点を返すのがとても容易になります。

<p>しかしながら結局、寄贈ソフトウェアの取扱は、実際に作業を行って
いる人々に委ねられています。
もしこの方法を使用することが、その人が扱っているパッケージには
極端に合わないような場合には、コアチームの承認さえあれば、これらの
ルールに反しても、他の開発者の一般的な合意は得られるでしょう。
将来にわたってパッケージを保守できるということは、大変重要な事柄に
なってきます。

<p>プログラミング言語 <tt>Tcl</tt> は、
この方法が活用されているよい例になっています:

<p><verb>src/contrib/tcl</verb> には、このパッケージの保守管理者が
配布したソースが含まれています。この中からは FreeBSD に完全には適用
できない部分が削除されています。Tcl の場合は、"mac"、 "win"、
"compat" というサブディレクトリは、FreeBSD に取り込む前に削除されて
いました。 

<p><verb>src/lib/libtcl</verb> には、ライブラリを生成したり、ドキュ
メントをインストールする際に使用される、標準の bsd.lib.mk の
規則を使用した「bmake スタイル」の Makefile だけが 含まれています。

<p><verb>src/usr.bin/tclsh</verb> には、bsd.prog.mk 規則 を使用して、
"tclsh" プログラムや関連するマニュアルページを生成 /インストール
する bmake スタイルの Makefile だけが含まれています。

<p><verb>src/tools/tools/tcl_bmake</verb> には、
tcl ソフトウェアを更新する必要が生じたときの助けになる2つのシェルス
クリプトが含まれています。これらは、ソフトウェアを構築するのに使用し
たり、インストール対象になるソフトウェアではありません。

<p>ここ重要なのは、"src/contrib/tcl" ディレクトリが、規則にしたがっ
て作られているということです。つまり、できるだけ FreeBSD に特化した
変更をおこなわないようにしたソースを(CVS のベンダブランチに)おくようにし
ています。   
freefall 上の「簡易取り込み」ツールは、寄贈ソフトウェアを取り込む手助
けとなります。けれども、このツールの実行方法に疑問が生じた場合は、ま
ずはじめに質問して、失敗をしないようにしてください。そして、
その疑問を「解決して」からツールを使用してください。
CVS に寄贈ソフトウェアを取り込む際には、事故があってはいけません。
よくあるような間違いをおかさないように、十分注意してください。

<p>CVS には、残念なことにベンダブランチという設計制限があります。このた
め、CVS に寄贈ソフトウェアを取り込むには、オリジナル配布ソースに 
適用されるベンダからの「公式」パッチと、ベンダブランチに逆輸入された結
果が必要です。 
ベンダブランチの一貫性を破壊したり、将来、新しいバージョンを取り込む
時に衝突を起こしてしまったりというような 困難な事態に陥らないように
しなければなりません。そのために、FreeBSD が管理しているバージョンに
対して、公式パッチを決して当ててはいけませんし、公式パッチを 
"commit" してはいけません。 

<p>多くのパッケージが、他のアーキテクチャや他の環境と FreeBSD 
との互換性を保ためのファイルをいくつか含んでいます。そこで、
スペースを節約するために、FreeBSD にとっては無意味な配布ツリー上の一
部を削除することが許されています。
けれども、削除されずに残ったファイルに対する、著作権の通知やリリース
ノートのような情報を含んだファイルは、決して削除しては <em> いけませ
ん </em>。 

<p>"bmake" Makefile が何らかのユーティリティによって、配布ツリーか
ら自動的に生成できると、うまくいけば、新しいバージョンへのアップグレー
ドをより簡単におこなうことができます。 
もしこのようなユーティリティを作成できた場合には、将来の管理者にとっ
て便利になるように、移植の際に、src/tools ディレクトリ上に、(必要に
応じて)そのユーティリティを必ずチェックインしてください。

<p> src/contrib/tcl レベルのディレクトリには、 README.FreeBSD と呼ば
れるファイルが追加されており、そのファイルでは 次のような内容が
記述されています。

<itemize>
 <item> ディレクトリ上に存在するファイル
 <item> オリジナルの配布物をどこから入手すればよいか また、公式配布
サイトはどこか 
 <item> オリジナルの作者にパッチを送り返すためには、どこに送ればよいか
 <item> FreeBSD に特化した変更点の概要
</itemize>