rename usage -> chapter, add more softwares, add gnats samples

3 files changed, 327 insertions, 101 deletions

diff --git a/fml/doc/ja/tutorial/ticketsystem/chapter.sgml b/fml/doc/ja/tutorial/ticketsystem/chapter.sgml
new file mode 100644
index 00000000..1d1d5a72
--- /dev/null
+++ b/fml/doc/ja/tutorial/ticketsystem/chapter.sgml
@@ -0,0 +1,178 @@
+<!--
+   $FML: usage.sgml,v 1.1.1.1 2001/10/22 03:30:28 fukachan Exp $
+-->
+
+<chapter id="ticketsystem.fml.usage">
+	<title>
+	ＭＬの話の筋(スレッド)の追跡 (Thread Tracking System ?)
+	</title>
+
+<para>
+fml 5.0 の問題意識は
+「ＭＬを走らせたら、スレッドのまとめくらい宜しくやって欲しい」
+ということです。
+あえていえば、インチキ knowledge database のようなものです。
+</para>
+
+<para>
+つまり楽ができるかわりにインチキです :-)
+が、大真面目に knowledge データベースだ、チケットシステムだ！
+とかいうと何億のシステム提案の世界らしいので、
+そんなのは欲しくありません(個人で使いたくないし、使える分けない)。
+</para>
+
+<para>
+商業ベースないしは運用ベースで考えるなら、より現実的な方法は、このぱち
+もん:) thread tracking system でノウハウをつみ、自分の組織に求められて
+いる用件は何か？を見究めることといえます。
+この第一段階があって、はじめて適正な knowledge base やticket system を
+構築/購入することができるに違いありません。
+もちろん、こんなもんで十分有用という場合もありえます:D
+</para>
+
+
+<sect1>
+	<title>
+	ＭＬの状態遷移
+	</title>
+
+<para>
+趣味の話をし合うＭＬは別として、
+多くの場合、『ＭＬにメールを投げる』とは
+「こういう問題を解決したい」
+とか
+「こういう問題があるけど、解決法が分からないから知りたい」
+ということであって、その意味で problem report といえます。
+そして、それに対してフォローアップがなされ、
+解決策が示されたり、未解決のまま放置されたりすることになります。
+</para>
+
+<para>
+これをモデル化すると、
+<screen>
+open    メールが投稿された時
+対応中  誰か返事をしたら、対応中
+closed  この問題について解決されたと判断された時
+
+メールの投稿  →   open 
+                    ↓
+フォローアップ→  対応中     
+                    ↓
+終りと判断        closed
+</screen>
+判断はモデレータなりを任命する必要があります。
+</para>
+
+<para>
+この点が最もつらい
+	<footnote>
+	<para>
+	どうしてもこれは必要で結局いつものように『最後は人』です。
+	つまり運用に携わる人間が一番大事だということです。
+	これは普遍的な命題です。
+	</para>
+	</footnote>
+ところです。
+誰か(人間)が判断する必要があるわけですし、
+その人は対象のＭＬでの会話の内容についてかなり理解を
+している必要もあります。
+</para>
+
+<para>
+日本語のあ・うんの呼吸で話が終ったと認定できればよいのですが
+それほど簡単ではありません。
+もっとも適当なキーワード「終了とかクローズします」などを
+基準にして判断することはできなくはないでしょう。
+これは将来の TODO といえるでしょう。
+</para>
+
+<para>
+終了のオペレーションは WWW かメールで行なうことを想定しています。
+つまりブラウザの上で操作するか、 
+メールの subject や本文に終了を意味する
+キーワードを送り込むことで行ないます。
+</para>
+
+</sect1>
+
+
+
+<!-- fml 5.0 モデル -->
+
+<sect1>
+	<title>
+	fml 5.0 (minimal_states モデル版)チケットシステム
+	</title>
+
+
+<sect2>
+	<title>
+	状態遷移
+	</title>
+
+<para>
+   open
+	チケット番号らしきものを含まないメールが投稿されたら
+	自動的に open
+</para>
+
+<para>
+  going
+	誰か返事をしたら、対応中
+</para>
+
+<para>
+  closed
+	close 宣言がなされたら、クローズ
+</para>
+
+</sect2>
+
+<sect2>
+	<title>
+	close 宣言は以下のいずれかの実行である。
+	</title>
+
+<para>
+1)	Subject: が close ではじまる
+</para>
+
+<para>
+   2)	メール本文の行頭が close ではじまる。
+		先頭の空白は無視されます。
+		正規表現では \s*close です。
+		
+		multipart メールの場合は最初の text/plain パートの
+		行頭が close で始まる場合です。
+</para>
+
+<para>
+   3)	メールヘッダで X-Ticket-Pragma: close が指定されていた時
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	特別なヘッダ
+	</title>
+
+<para>
+X-Ticket-Pragma: ignore
+
+	新たにチケットを割り当てない
+	すべてのチケットに関する操作を抑制する。
+</para>
+
+<para>
+X-Ticket-Pragma: close
+
+	チケットをクローズする。
+</para>
+
+</sect2>
+
+</sect1>
+
+</chapter>
diff --git a/fml/doc/ja/tutorial/ticketsystem/tools.sgml b/fml/doc/ja/tutorial/ticketsystem/tools.sgml
index 5991d3d1..bd1ce7d9 100644
--- a/fml/doc/ja/tutorial/ticketsystem/tools.sgml
+++ b/fml/doc/ja/tutorial/ticketsystem/tools.sgml
@@ -1,5 +1,5 @@
 <!--
-   $FML: ticket.sgml,v 1.1 2001/06/10 12:58:30 fukachan Exp $
+   $FML: tools.sgml,v 1.1.1.1 2001/10/22 03:30:28 fukachan Exp $
 -->
 
 <chapter id="ticketsystem.pmtools.summary">
@@ -16,7 +16,7 @@ bug tracking システムとチケットシステムは微妙に目的が違うと思うが、
 <ulink url="http://www.daveeaton.com/scm/PMTools.html">
 http://www.daveeaton.com/scm/PMTools.html
 </ulink>
-に FAQ がある。
+に FAQ 
 	<footnote>
 	<para>
 	<ulink url="http://www.iac.honeywell.com/Pub/Tech/CM/PMTools.html">
@@ -25,18 +25,35 @@ http://www.daveeaton.com/scm/PMTools.html
 	に昔あった？
 	</para>
 	</footnote>
-特に売りもの一覧についてはここをまず見られたい。
+がある。特に売りもの一覧についてはここをまず見られたい。
 Free のものもいくつかある。
 最も有名なものは GNATS かもしれないが、
-<screen>
-Bugzilla 
+あとは 
 jitterbug
-</screen>
-などが有名だろうか？ 
+がよくみるだろうか？
+他に
+Bugzilla 
+とか
 debuggs (Debian Bug Tracking System)
-や OpenTrack PTS WREK Wreq (?) などというのもある。
+とか OpenTrack PTS WREK Wreq (?) などというのもある。
+</para>
+
+<para>
+あ、こっちの linux もののページ
+<ulink url="http://linas.org/linux/pm.html">
+http://linas.org/linux/pm.html
+</ulink>
+の方がよくまとまってるかもしれない。
+</para>
+
+<para>
 どちらかというと有名なものは特定のプロジェクトと bind されていて
-そこから派生したという趣があるようにおもえる。
+そこから派生したという趣が多いようにおもえます。
+例えば perl.org のバグトラックツールである perlbug (CPAN を見よ) は
+他であまり使われているような気がしないわけで、
+どうも project が発生するたびに、
+『既存の bug tracking system は使いにくい、作ろう』
+という project が付随して発生しているような気もします(笑)
 </para>
 
 
@@ -47,7 +64,7 @@ debuggs (Debian Bug Tracking System)
 
 <para>
 Call Tracking は主にお客からの問題の指摘についての扱いであり
-人の割り当てとステータス管理とレポートを行なう必要がある。
+人の割り当てとステータス管理とレポートを行なう必要があります。
 </para>
 
 <para>
@@ -55,12 +72,12 @@ Call Tracking は主にお客からの問題の指摘についての扱いであり
 開発プロセスの管理などであり、
 その管理対象には
 タスクやさまざまな統計やレポートだけでなく、
-インテグレーションやそのテストまでも含まれうる。
+インテグレーションやそのテストまでも含まれえます。
 </para>
 
 <para>
 なお Configuration Management という単語も Problem Tracking の
-近隣に位置するが、これは CVS などのツール系のことである。
+近隣に位置するが、これは CVS などのツール系のことです。
 </para>
 
 </sect1>
@@ -89,10 +106,7 @@ RESOLVED
 VERIFIED
 CLOSED
 </screen>
-などもある。
-</para>
-
-<para>
+などもあります。
 jitterbug だと
 <screen>
 all
@@ -100,7 +114,121 @@ pending
 replied
 unreplied
 </screen>
-にあたるのかな?(でいいのか?)
+が、status にあたるものかなあ？(でいいのか?)
+</para>
+
+</sect1>
+
+
+<sect1>
+	<title>
+	GNATS (GNU Problem Report Management System)
+	</title>
+
+<para>
+ご存知、有名な bug tracking system。
+まぁとにかく GNATS の実例を見よう〜
+<ulink url="http://www.netbsd.org/Misc/send-pr.html">
+http://www.netbsd.org/Misc/send-pr.html
+</ulink>
+</para>
+
+<para>
+send-pr の例
+<screen>
+To: gnats-bugs@gnats.netbsd.org
+Subject: no definition for 9801N-J12 pcmcia card
+From: fukachan@fml.org
+Reply-To: fukachan@fml.org
+X-send-pr-version: 3.95
+
+
+&gt;Submitter-Id:	net
+&gt;Originator:	Ken'ichi Fukamachi
+&gt;Organization:	fml.org
+&gt;Confidential:	no
+&gt;Synopsis:	no definition for 9801N-J12 pcmcia card
+&gt;Severity:	non-critical
+&gt;Priority:	low
+&gt;Category:	kern
+&gt;Class:		sw-bug
+&gt;Release:	NetBSD 1.5.1_BETA2
+&gt;Environment:
+
+System: NetBSD rudo.home.fml.org 1.5.1_BETA2 NetBSD 1.5.1_BETA2 (BETH) #0: Thu Sep 27 12:09:39 JST 2001 fukachan@rudo.home.fml.org:/usr/NetBSD-release-1-5/src/sys/arch/i386/compile/BETH i386
+
+&gt;Description:
+
+NEC 9801N-J12 pcmcia card does not work with NetBSD/i386 (netbsd-1-5
+branch).  NetBSD kernel detects it as "ne" but it cannot be
+configured.
+
+I do not test it with NetBSD-current but it looks NetBSD-current has
+no definition for this card.
+
+&gt;How-To-Repeat:
+
+attach it. 
+
+&gt;Fix:
+
+apply the following patch.
+
+By the way, this card looks an OEM of IBM INFOMOVER.
+So, the following definition may be more appropriate ?
+
+   { PCMCIA_STR_NEC_9801N_J12,
+     PCMCIA_VENDOR_IBM, PCMCIA_PRODUCT_IBM_INFOMOVER,
+     PCMCIA_CIS_NEC_9801N_J12,
+     0, 0xff0, { 0x00, 0x00, 0x4c } },
+
+
+
+Index: if_ne_pcmcia.c
+===================================================================
+RCS file: /cvsroot/syssrc/sys/dev/pcmcia/if_ne_pcmcia.c,v
+retrieving revision 1.62.4.5
+diff -u -u -b -r1.62.4.5 if_ne_pcmcia.c
+--- if_ne_pcmcia.c	2001/06/16 19:18:50	1.62.4.5
++++ if_ne_pcmcia.c	2001/09/26 09:42:26
+@@ -200,6 +200,11 @@
+       PCMCIA_CIS_SVEC_PN650TX,
+       0, -1, { 0x00, 0xe0, 0x98 }, NE2000DVF_DL10019 },
+ 
++    { PCMCIA_STR_NEC_9801N_J12,
++      PCMCIA_VENDOR_NEC, PCMCIA_PRODUCT_NEC_9801N_J12,
++      PCMCIA_CIS_NEC_9801N_J12,
++      0, 0xff0, { 0x00, 0x00, 0x4c } },
++
+     /*
+      * This entry should be here so that above two cards doesn't
+      * match with this.  FNW-3700T won't match above entries due to
+Index: pcmciadevs
+===================================================================
+RCS file: /cvsroot/syssrc/sys/dev/pcmcia/pcmciadevs,v
+retrieving revision 1.93.2.7
+diff -u -u -b -r1.93.2.7 pcmciadevs
+--- pcmciadevs	2001/06/16 19:19:12	1.93.2.7
++++ pcmciadevs	2001/09/26 09:42:26
+@@ -43,6 +43,7 @@
+ vendor FUJITSU			0x0004  Fujitsu Corporation
+ vendor PANASONIC		0x0032	Matsushita Electric Industrial Co.
+ vendor SANDISK			0x0045	Sandisk Corporation
++vendor NEC                      0x00a4  NEC
+ vendor NEWMEDIA			0x0057	New Media Corporation
+ vendor INTEL			0x0089	Intel
+ vendor IBM			0x00a4	IBM Corporation
+@@ -83,6 +84,9 @@
+ /*
+  * List of known products.  Grouped by vendor.
+  */
++
++/* NEC */
++product NEC 9801N_J12		0x0002 NEC	PC-9801N-J12	LAN
+ 
+ /* Adaptec Products */
+ product ADAPTEC APA1460		0x0001 Adaptec APA-1460 SlimSCSI
+</screen>
 </para>
 
 </sect1>
@@ -117,11 +245,13 @@ http://samba.anu.edu.au/jitterbug/
 </ulink>
 を参照。
 割と simple is best 指向なものといえるだろうか。
-WWW インターフェイスのみ。
-(URL みりゃわかるとおり)
 もともとは samba の bug tracking をする目的からスタート。
+C 言語で、WWW インターフェイスのみ
+(URL みりゃわかるとおり)。
 </para>
 
+</sect1>
+
 
 <sect1>
 	<title>
diff --git a/fml/doc/ja/tutorial/ticketsystem/usage.sgml b/fml/doc/ja/tutorial/ticketsystem/usage.sgml
deleted file mode 100644
index 7f8b8e36..00000000
--- a/fml/doc/ja/tutorial/ticketsystem/usage.sgml
+++ /dev/null
@@ -1,82 +0,0 @@
-<!--
-   $FML: ticket.sgml,v 1.1 2001/06/10 12:58:30 fukachan Exp $
--->
-
-<chapter id="ticketsystem.fml.usage">
-	<title>
-	fml 5.0 (minimal_states モデル版)チケットシステムの使い方
-	</title>
-
-<sect1>
-	<title>
-	状態遷移
-	</title>
-
-<para>
-
-</para>
-
-<para>
-   open
-	チケット番号らしきものを含まないメールが投稿されたら
-	自動的に open
-</para>
-
-<para>
-  going
-	誰か返事をしたら、対応中
-</para>
-
-<para>
-  closed
-	close 宣言がなされたら、クローズ
-</para>
-</sect1>
-
-
-<sect1>
-	<title>
-	close 宣言は以下のいずれかの実行である。
-	</title>
-
-<para>
-1)	Subject: が close ではじまる
-</para>
-
-<para>
-   2)	メール本文の行頭が close ではじまる。
-		先頭の空白は無視されます。
-		正規表現では \s*close です。
-		
-		multipart メールの場合は最初の text/plain パートの
-		行頭が close で始まる場合です。
-</para>
-
-<para>
-   3)	メールヘッダで X-Ticket-Pragma: close が指定されていた時
-</para>
-
-</sect1>
-
-
-<sect1>
-	<title>
-	特別なヘッダ
-	</title>
-
-<para>
-X-Ticket-Pragma: ignore
-
-	新たにチケットを割り当てない
-	すべてのチケットに関する操作を抑制する。
-</para>
-
-<para>
-X-Ticket-Pragma: close
-
-	チケットをクローズする。
-</para>
-
-</sect1>
-
-</chapter>