HardenedBSD/share/doc/ja_JP.EUC/handbook/policies.sgml

<!-- $Id$ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.10 -->

<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>

<sect><heading>共有ライブラリ
<label id="policies:shlib">
</heading>

<p><em>Contributed by &a.asami;, &a.peter;, and &a.obrien;.
  <newline>9 December 1996.</em></p>

  <p>もしあなたが共有ライブラリをサポートする機能を port に追加した
     り, 共有ライブラリをサポートしていない他のソフトウェアに追加する
     場合には, 共有ライブラリのバージョン番号を次の規則にしたがって
     つけてください.  
     一般的には, この規則は, ソフトウェアのリリースバージョンとは
     全く関係ありません. 
  <p>共有ライブラリを作成する三つの重要な規則は次の通りです:

  <itemize>
    <item>1.0 から始める
    <item>過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす
    <item>互換性のない変更の場合は, メジャー番号を増やす
  </itemize>

  <p>例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします.
     機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 
     強制的にメジャー番号を変更します. 

  <p>メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. 
     FreeBSD のダイナミックリンカは, x.y.z という形式のバージョン番号
     は扱えません.
     この場合, 「y」の後のバージョン番号(つまり三つ目の数字)は,
     どのライブラリがリンクされているかを決めるために, 共有ライブラ
     リ番号を比較する際に, すべて無視されます.
     「小さな」リビジョンだけが異なる二つの共有ライブラリが指定
     されると, ld.so は, リビジョンの大きい方の共有ライブラリを
     リンクします. すなわち, もしあなたが libfoo.so.3.3.3 をリンク
     していたとすると, リンカは頭の 3.3 という部分だけを認識し, 
     libfoo.so.3 ではじまり その後に 3 以上の数字が続くもののうち、
     最も大きい番号の付いているライブラリをリンクします. 
  <p>ld.so はいつも最も大きい「マイナー」リビジョンのものを使うことに
     注意してください. 例えば, プログラムがはじめ libc.so.2.0 を
     リンクしていたとしても, libc.so.2.0 よりも libc.so.2.2 を優先
     して使用します.

  <p>移植されていないライブラリに対しては, リリースごとに共有ライブラリの
     バージョン番号を一度だけ変更するのが私たちのポリシーです.
     あなたがシステムライブラリのバージョン番号を上げた場合は,
     Makefile の commit ログを確認してください.
     結果としてそのリリースには, 共有ライブラリのバージョン番号が
     アップデートされた Makefile に入るので、最初にその変更を
     確かめるのがソースツリー管理者 ("committer") の責務です.
     その後のどんな変更も, そのリリースには入りません.