aboutsummaryrefslogtreecommitdiff
path: root/ja_JP.eucJP/articles/problem-reports/article.sgml
blob: 54a758cc080ab749dba6175411bc1b4ee0d4f65d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
<!--
   The FreeBSD Japanese Documentation Project
   Original revision: 1.23
   $FreeBSD$
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
%man;
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//JA">
%mailing-lists;
<!ENTITY % ja-authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//JA">
%ja-authors;
]>

<article>
  <articleinfo>
    <title>FreeBSD 障害報告の書き方</title>

    <pubdate>$FreeBSD$</pubdate>

    <abstract>
      <para>この記事では、明瞭な障害報告 (Problem Report: PR) を
	FreeBSD プロジェクトに提出する方法を解説します。</para>
    </abstract>

    <authorgroup>
      <author>
	<firstname>Dag-Erling</firstname>
	<surname>Sm&oslash;rgrav</surname>
	<contrib>寄稿: </contrib>
      </author>
    </authorgroup>
  </articleinfo>

  <indexterm><primary>障害報告</primary></indexterm>

  <section id="pr-intro">
    <title>はじめに</title>

    <para>ソフトウェアの利用者が持っている
      多くのいらただしい経験のうちの一つは、
      <quote>それはバグじゃない</quote><quote>ひどい障害報告だ</quote>
      などのようなそっけなく理解の役に立たない説明によって、
      障害報告があっさり片付けられてしまうことです。
      同様に、ソフトウェア開発者が持っている
      多くのいらただしい経験のうちの一つは、
      実際は障害報告ではない単なるサポート要求や
      何が問題でどのように再現するかについての情報が
      乏しいまたは欠落している障害報告が殺到することです。</para>

    <para>この記事では、上手な障害報告の書き方についての説明を試みています。
      上手な障害報告とは何かって?
      そうですね、単刀直入に要点を言えば、
      上手な障害報告とは、迅速に解析を進め処理を行うことができ、
      一度に利用者と開発者がお互いに満足できるものです。</para>

    <para>この記事では主として FreeBSD の障害報告に焦点を絞っていますが、
      他のソフトウェアプロジェクトでも多くの部分が当てはまるでしょう。</para>

    <para>この記事は、テーマ別に整理されていますが順番にはなっていません。
      ステップバイステップのチュートリアルとして利用するのではなく、
      障害報告を提出する前に全体を通して読むべきです。</para>
  </section>

  <section id="pr-when">
    <title>いつ障害報告を提出すればよいのか</title>

    <para>多くの種類の問題がありますが、
      それらすべてが障害報告を引き起こすわけではありません。
      もちろん、誰しもが完璧ではありませんので、
      実際はコマンドの構文を勘違いしていたり、
      設定ファイルに書き間違いをしている場合などを
      プログラムにバグを見つけた! と思い込んでしまうことがあるでしょう
      (とは言っても、それ自身、文書が適切に記述されていなかったり、
      アプリケーションのエラー処理が甘いことを暗示している可能性があります)。
      それでもなお、障害報告を提出することが正しい行動ではない場合が多々あり、
      あなたや開発者達をただ
      不満にさせるためだけに作用してしまうことがあります
      (訳注: はっきりと把握していないことを報告すべきではありません。
      要領を得ない障害報告は扱いにくいものです)。
      逆に、バグというよりも、
      何か別の報告として提出した方が適切な場合があります &mdash;
      たとえば、既存機能の拡張や新しい機能の搭載要求のようなものです。</para>

    <para>そうすると、何がバグで何がバグでないのか、
      どのようにして決めれば良いでしょうか?
      簡単な経験則として、それを質問として表現できるなら
      あなたの問題はバグでは<emphasis>ありません</emphasis>
      (<quote>X をどのようにすればよいですか?</quote><quote>Y はどこで見つけることができますか?</quote> が一般的な形式です)。
      いつも白黒はっきりするわけではありませんが、
      この質問規則は問題の非常に多くの部分があてはまります。
      もし、このような質問に対する答えを求めているのなら、
      &a.questions; にあなたの質問を送ってみることを検討してください。</para>

    <note>
      <title>訳注</title>

      <para>&a.questions; へのメールは英語でお願いします。
	日本語にでの質問は、&a.jp.users-jp; か
	<email>FreeBSD-beginners-jp@ux.mycom.co.jp</email>
	などに送ってください。</para>
    </note>

    <para>バグではないものに関する障害報告を
      提出することが適切かもしれない条件は、以下のような時です:</para>

    <itemizedlist>
      <listitem>
	<para>機能拡張の要求。
	  障害報告を提出する前に、メーリングリストに
	  これらのことを表明することは一般的に良い考えです。</para>
      </listitem>

      <listitem>
	<para>外部で管理されているソフトウェアの更新通知
	  (主に ports のことです。BIND やさまざまな GNU ユーティリティのような
	  システムの基礎を構成するソフトェアは外部的に管理されていますが、
	  ここでは除きます)。</para>
      </listitem>
    </itemizedlist>

    <para>もう一つ、もし、バグに遭遇したシステムが実際には最新でない場合、
      システムを最新の状態にして、最新のシステムでも問題が再現するか試した後に
      障害報告を提出することを真剣に考えるべきだということです。
      既に修正されたバグに関する障害報告を受けとること以上に、
      開発者を悩ませるものはほとんどありません。</para>

    <para>最後に、再現することができないバグは、めったに直すことができません。
      もし、バグが一度だけ発生してそれが再現できないもので、
      なおかつ他の人のシステムでも起こらないようであれば、
      開発者はそれを再現しようとしてもできませんし、
      何が悪いのか理解する機会もありません。
      これはバグが起こらなかったことを意味するわけではありません。
      しかし、このような状況ではあなたの障害報告がバグの修正に
      つながる見込みは非常に薄く、報告をやめることを検討すべきです。</para>
  </section>

  <section id="pr-prep">
    <title>準備</title>

    <para>従うべき良い規則として、
      障害報告を提出する前に常に問題の背景を調べることです。
      おそらく、あなたの問題は既に報告されています。
      また、メーリングリストで議論されていたり、
      最近議論されていたことでしょう。
      さらに、あなたが動かしているものより、
      既に修正された新しいバージョンがあるかもしれません。
      したがって、障害報告を提出する前に明白な部分をすべて確認すべきです。
      FreeBSD では、以下のような方法があります:</para>

    <itemizedlist>
      <listitem>
	<para>FAQ を調べる。</para>
      </listitem>

      <listitem>
	<para>
	  <ulink
	    URL="../../books/handbook/eresources.html#ERESOURCES-MAIL">
	    メーリングリスト</ulink>を利用する。
	  &mdash; メーリングリストを購読していなければ、
	  FreeBSD のウェブサイトにある
	  <ulink
	    URL="http://www.FreeBSD.org/search/search.html#mailinglists">
	    アーカイブ検索</ulink>を使ってください。
	  もし、メーリングリストで議論がされていなければ、
	  自分の問題についてのメッセージを送ってみて、
	  見落とした点を誰かが見つけてくれるかどうか
	  数日間待ってみると良いでしょう。</para>
      </listitem>

      <listitem>
	<para>ウェブ全体を検索する (任意)。&mdash;
	  あなたの問題に関係する話題がないか
	  あなたのお気に入りの検索エンジンを使って探します。
	  アーカイブされたメーリングリストやニュースグループを
	  隅々まで検索すれば、知らなかったまたは思いもつかなかった結果を
	  得ることができるかもしれません。</para>
      </listitem>

      <listitem>
	<para>最後に、FreeBSD 障害報告データベースを調べる。
	  あなたの問題が新しいものでなかったり不明瞭であれば、
	  既に報告されている可能性がかなりあります。</para>
      </listitem>
    </itemizedlist>

    <para>次に、障害報告が適切な人物に届くことを確認する必要があります。</para>

    <para>まず、問題がサードパーティソフトウェアのバグであれば、
      原作者に報告をすべきです。
      そうでなければ、FreeBSD プロジェクトに報告してください。
      このルールには二つの例外があります。
      一つ目は、もしバグが他のプラットフォームで発生しなければ、
      FreeBSD に移植されたソフトウェアに原因が存在する場合です。
      二つ目は、原作者がバグを既に修正していて
      そのソフトウェアの新しいバージョンかパッチを公開しているが、
      FreeBSD に移植されたソフトウェアがまだ更新されていない場合です。</para>

    <para>それから、FreeBSD のバグ追跡システムは
      発信者が選択した分類に従って
      障害報告を分別しているということに注意してください。
      もし間違った分類を選択した場合、あなたが送った障害報告は
      誰かが再分類する良い機会がくるまでしばらく見落とされるでしょう。</para>
  </section>

  <section id="pr-writing">
    <title>障害報告の書き方</title>

    <para>自分の問題が障害報告を行うに値すると結論を出し、
      そしてそれが FreeBSD の問題点であると判断したのですから、
      実際に障害報告を執筆する時です。
      環境変数 <envar>VISUAL</envar>
      (か、もし <envar>VISUAL</envar>
      が設定されていなければ <envar>EDITOR</envar>)
      が何らかの使える値に設定されているか確認して、
      &man.send-pr.1; を実行します。</para>

    <section>
      <title>パッチやファイルを添付する</title>

      <para>&man.send-pr.1; プログラムは、
	障害報告にファイルを添付する機能を備えています。
	あなたが望む数だけ、それぞれ一意の名前を持ったファイル
	(すなわち、パスを除いた適切な名前のファイル)
	を添付することができます。
	コマンドラインオプション <option>-a</option> で
	添付するファイルの名前を指定してください:</para>

<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput></screen>

      <para>添付するファイルがバイナリであっても心配しないでください。
	メールエージェントが混乱しないように、自動的に符合化が行われます。</para>

      <para>パッチは context 形式か unified 形式の差分を &man.diff.1; の
	<option>-c</option><option>-u</option> オプションを
	使って作成してください。
	パッチを添付する場合、
	開発者があなたの報告を読んで簡単にパッチを適用できるように、
	修正したファイルの正確な CVS のリビジョン番号が特定できるか
	確認してください。</para>

      <para>一般的に、
	障害報告の中に小さなパッチを含める分にはいいのですが、
	記載される問題についての修正が大規模な場合や新しいコードの場合は
	十分な査読を行なった後にコミットすべきであるため、
	パッチを Web や FTP サーバに置き、その URL を障害報告に含めてください。
	電子メールに含めたパッチはサイズが大きいと分割される傾向にあり
	(とりわけ Gnats が処理に関わるときはそうです)、
	肝心な部分が変にならないように注意をはらってください。
	また、パッチに変更があった場合、
	元の障害報告へのフォローアップとしてパッチ全体を再提出しなくとも
	Web から該当部分のパッチを送信して変更することができます。</para>

      <para>また、障害報告かパッチ自体に明確に指定がなければ、
	あなたが提出したパッチは修正した元のファイルと同じ条件の
	ライセンス下にあるものと仮定されることに留意しておくべきです。</para>
    </section>

    <section>
      <title>テンプレートに記入する</title>

      <para>テンプレートは特定のフィールドから成り立っており、
	あらかじめ書き込まれた部分がいくつかあります。そこには
	フィールドの目的が何かを説明する解説や
	そのフィールドに利用可能な値が書かれています。
	コメントの部分は、自分で変更・削除しなくても、
	自動的に削除されますので心配する必要はありません。</para>

      <para>テンプレートの先頭にある <literal>SEND-PR:</literal>
	と書かれている行の下が電子メールのヘッダです。
	通常、この部分を変更する必要はありませんが、
	障害報告を送信する機械やアカウントで
	メールを出すことはできるが受けとることができない場合、
	<literal>From:</literal><literal>Reply-To:</literal> に
	実際のメールアドレスを設定すべきです。
	また、自分 (や他の誰か) に障害報告の複製を送りたい場合は、
	電子メールアドレスを
	<literal>Cc:</literal> ヘッダに追加してください。</para>

      <para>次に、一連の一行フィールドが続きます:</para>

      <note>
	<title>訳注</title>

	<para>フィールドの意味が分かり易いように
	  フィールド名を訳していますが、
	  フィールドの値も含めて
	  実際のフィールド名は英文字である必要があります。</para>
      </note>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Submitter-Id (提出者-Id):</emphasis>
	  これは変更しないでください。
	  あなたが FreeBSD-STABLE を動かしている場合でも、既定値である
	  <literal>current-users</literal> が正しいのです。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Originator (あなたの名前):</emphasis>
	    これは普通、現在ログインしているユーザの
	    GECOS フィールドを使って既に埋められています。
	    あなたの実際の名前を指定してください。
	    お好みで、名前の後ろに電子メールアドレスを
	    山括弧 (&lt;&gt; のこと) で閉じて付けることができます。</para>

	  <note>
	    <title>訳注</title>

	    <para>たとえば、以下のように書くことができます。</para>

	    <screen>From: <userinput>FreeBSD Taro &lt;FreeBSD-Taro@example.org&gt;</userinput></screen>
	  </note>
	</listitem>

	<listitem>
	  <para><emphasis>Organization (所属組織):</emphasis>
	    あなたが望むのなら好きに使えます。
	    このフィールドは何らかの深い意味で使われることはありません。 </para>
	</listitem>

	<listitem>
	  <para><emphasis>Confidential (機密):</emphasis>
	    これは <literal>no</literal> で既に埋められています。
	    機密扱いの FreeBSD 障害報告のようなものはないため、
	    変更することに意味はありません。&mdash;
	    障害報告データベースは <application>CVSup</application> によって、
	    世界的に配布されています。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Synopsis (概要):</emphasis>
	    問題についての簡にして要を得た説明を書き込んでください。
	    概要は障害報告メールのサブジェクトとして利用されており、
	    一覧や要旨にも使われています。
	    概要が不明瞭な障害報告は無視される傾向があります。</para>

	  <para>障害報告にパッチを添付する場合、概要の先頭に
	    <literal>[PATCH]</literal> と書いてください。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Severity (重要度):</emphasis>
	    <literal>non-critical (重要ではない)</literal><literal>serious (重要)</literal><literal>critical (致命的) </literal> のどれかです。
	    重要度を過大に評価しないでください。
	    あなたの問題が本当に致命的 (たとえば、
	    <username>root</username> 権限を悪用できたり、
	    パニックを容易に再現できるなど) でない場合は、
	    <literal>critical</literal> に分類するのは控えてください。
	    障害報告を提出する人達は自分の問題を大げさに評価しがちであり、
	    そのため開発者はこのフィールドや次のフィールドを無視する傾向があります。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Priority (優先順位):</emphasis>
	    <literal>low (低い)</literal><literal>medium (中間)</literal><literal>high (高い)</literal> のどれかです。
	    分類の基準は前述されてますので読んでください。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Category (分類):</emphasis>
	    以下から一つを選んでください:</para>
	  <itemizedlist>
	    <listitem>
	      <para><literal>advocacy:</literal>
		FreeBSD の一般像に関する問題。めったに使われません。</para>
	    </listitem>

	    <listitem>
	      <para><literal>alpha:</literal>
		Alpha プラットフォーム固有の問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>bin:</literal>
		基本システムに含まれるユーザランドプログラムに関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>conf:</literal>
		設定ファイルや、既定値などに関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>docs:</literal>
		マニュアルページ、オンライン文書に関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>gnu:</literal>
		&man.gcc.1; や &man.grep.1; などの
		GNU ソフトウェアに関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>i386:</literal>
		i386 プラットフォーム固有の問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>ia64:</literal>
		ia64 プラットフォーム固有の問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>java:</literal>
		Java&trade; に関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>kern:</literal>
		カーネルに関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>misc:</literal>
		これらの分類に適合しないその他の分類。</para>
	    </listitem>

	    <listitem>
	      <para><literal>ports:</literal>
		ports ツリーに関する問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>powerpc:</literal>
		PowerPC プラットフォーム固有の問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>sparc64:</literal>
		SPARC プラットフォーム固有の問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>standards:</literal>
		標準規格への適合問題。</para>
	    </listitem>

	    <listitem>
	      <para><literal>www:</literal>
		FreeBSD ウェブサイトへの変更と改善。</para>
	    </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Class:</emphasis> 以下から一つを選んでください:</para>

	  <itemizedlist>
	    <listitem>
	      <para><literal>sw-bug:</literal>
		ソフトウェアのバグ。</para>
	    </listitem>

	    <listitem>
	      <para><literal>doc-bug:</literal>
		文書中の間違い。</para>
	    </listitem>

	    <listitem>
	      <para><literal>change-request:</literal>
		機能の追加や、既存の機能の変更についての要望。</para>
	    </listitem>

	    <listitem>
	      <para><literal>update:</literal>
		ports やその他の寄贈ソフトウェアに対する更新。</para>
	    </listitem>

	    <listitem>
	      <para><literal>maintainer-update:</literal>
		保守者の ports に対する更新。</para>
	    </listitem>
	  </itemizedlist>
	</listitem>

	<listitem>
	  <para><emphasis>Release:</emphasis>
	    あなたが動作させている FreeBSD のバージョン。
	    これは &man.send-pr.1; によって自動的に書き込まれますが、
	    もし、あなたが障害が起きているものと違うシステムから障害報告を
	    送信する場合に限り変更する必要があります。</para>
	</listitem>
      </itemizedlist>

      <para>最後に、一連の複数行フィールドがあります:</para>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Environment (環境):</emphasis>
	    問題が発生した環境を可能な限り正確に記述すべきです。
	    ここには、オペレーティングシステムのバージョン、
	    特定のプログラムのバージョンまたは問題があるファイル、
	    そしてシステムの設定などのような関係する項目、
	    問題に影響を及ぼすインストールしたその他の
	    ソフトウェアなどが含まれます。&mdash;
	    その問題が生じる環境を再構築するために、
	    開発者はなんでも知る必要があります。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Description:</emphasis>
	    あなたが経験した問題の完全で正確な説明。
	    開発者が誤解してしまうかもしれないので、
	    問題の原因について正しく追跡ができたと確信していない限り
	    推測は避けるようにしてください。</para>
	</listitem>

	<listitem>
	  <para><emphasis>How-To-Repeat:</emphasis>
	    問題を再現させるために取る必要のある行動の概要。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Fix:</emphasis>
	    できればパッチか、少なくとも回避方法を記述する
	    (同じ問題を回避する方法として他の人達の助けになるだけではなく、
	    開発者が問題の原因を理解する役に立つかもしれません) べきですが、
	    はっきりとしたアイデアがなければ開発者が思索をめぐらすために、
	    このフィールドは空にしておけば良いでしょう。</para>
	</listitem>
      </itemizedlist>
    </section>

    <section>
      <title>障害報告を送信する</title>

      <para>テンプレートを書き終えて、
	保存してエディタを終了すると、&man.send-pr.1; は
	<prompt>s)end, e)dit or a)bort?</prompt> のような
	表示を出して指示を求めます。
	<userinput>s</userinput> を押せば障害報告の提出に進めますし、
	<userinput>e</userinput> だとエディタが再び実行されてさらに編集できます。
	<userinput>a</userinput> なら作業を中止できます。
	abort を選択した場合、いままで書いていた障害報告はディスクに残りますので
	(&man.send-pr.1; は終了前にそのファイル名を示します)、
	暇な時にそれを編集したり、場合によっては
	よりネットワーク接続性のよいシステムに持っていくことができるでしょう。
	この作業ファイルは、&man.send-pr.1; の
	<option>-f</option> オプションを使って送ることができます:</para>

<screen>&prompt.user; <userinput>send-pr -f ~/my-problem-report</userinput></screen>

      <para>上記の操作では、指定されたファイルを読み込み、
	書式が正しいか検証し、ファイル中のコメント部分を取り除いて、
	障害報告が送信されます。</para>
    </section>

  </section>

  <section id="pr-followup">
    <title>フォローアップ</title>

    <para>障害報告を提出すると、
      障害報告に割り当てられた追跡用の番号と
      状況を確認するために利用する URL を含む、
      確認のための電子メールが送られてくるでしょう。
      ちょっぴり運がよければ、誰かがあなたの問題に興味を持って
      それについて取り組もうとするでしょうし、
      場合によってはなぜそれが問題でないか説明してくれるでしょう。
      状況に何かの変更があると、
      誰かがあなたの障害報告を審査追跡状態にして、
      何らかのコメントかパッチの通知を自動的に受けとるでしょう。</para>

    <para>誰かがあなたにさらなる情報を求めたり、
      最初の報告の中で言及しなかったものを思い出したり発見したら、
      バグ追跡システムがどの障害報告に結びつければよいか知るために、
      件名に追跡用の数字が含まれているかを確かめて
      <email>bug-followup@FreeBSD.org</email> にメールを送ってください。</para>

    <para>問題がなくなったのに障害報告の処理が完了していなければ、
      できれば、どのように、いつ、問題を解決できたかの説明を添えて、
      この障害報告は議論を終了することができます、と
      (前述の方法で) フォローアップを送ってください。</para>
  </section>

  <section id="pr-further">
    <title>さらなる読みもの</title>

    <para>適切な障害報告の書き方と手順について関連する資料を示しますが、
      決して完全なものではありません。</para>

    <itemizedlist>
      <listitem>
	<para><ulink
	    url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">
	    効果的にバグを報告するには</ulink>
	  (<ulink
	    url="http://www.unixuser.org/~ueno/bugs-ja.html">
	      日本語訳</ulink>) &mdash;
	  Simon G. Tatham 氏による、(FreeBSDに限らない)
	  役に立つ障害報告の作成についてのすぐれたエッセイ。</para>
      </listitem>
      <listitem>
	<para><ulink
	    url="../../../en_US.ISO8859-1/articles/pr-guidelines/article.html">
	  障害報告 取り扱いガイドライン</ulink> &mdash;
	  障害報告が FreeBSD の開発者によってどのように
	  扱われるかについて有益な見識をまとめた記事。</para>
      </listitem>
    </itemizedlist>
  </section>
</article>