バグレポートの記述方法(新たなバグレポートを追加する)
著者: 森 洋久 / joshua＠globalbase.org ※* 概要
* この作業に必要となる知識
* この作業の前提となるシステム用件
* [ステップ1] バグレポートの構成
* [ステップ2] レポートコードの決定
* [ステップ3] バグレポートアイテムの追加
* [ステップ4] バグレポートアイテムのCVSへの追加
* [ステップ5] バグレポート本体ファイルの更新
* [ステップ6] コンパイル
* [ステップ7] HTMLおよびPDFの確認
* [ステップ8] HTMLの公開
* [ステップ9] CVSチェックイン
概要
バグレポートの記述方法は、基本的には通常のマニュアルのアップデート ( 「既にあるマニュアルを編集する手順」)と同じですが、ファイル構成が異なっています。そのため、更新作業が異なる部分があります。▲ページトップへ戻る
この作業に必要となる知識
バグを発見し、報告してくれる人物は多いに歓迎です。現在、多くの場合、そのようなレポートは開発者または、GLOBALBASEの各種メーリングリストに寄せられます。このバグレポートはこのような開発者、つまり、CVSをコントロールできるであろう人たちへ寄せられることを前提としています。こういった開発者がこのマニュアルに新たなバグレポートを追加するということを前提としています。▲ページトップへ戻る
この作業の前提となるシステム用件
本手順は、ソースコードの開発環境をそろえていることを前提としています。以下のファイルの保存場所などは、sourceforge.jpのCVSからコミットしたワークエリアに対する操作を説明しています。sourceforge.jpからのCVSの取得方法等については、 文献「GLOBALBASEの開発」を参照してください。▲ページトップへ戻る
[ステップ1] バグレポートの構成
バグレポートのファイル構成は 表(バグレポートファイル構成)の通りになっています。| gbs/doc/xml/src/xml/ja-bugs-report.xml | バグレポートXML本体 |
| gbs/doc/xml/src/xml/bugs-reports | バグレポートアイテムの入ったディレクトリ |
| gbs/doc/xml/src/xml/bugs-reports/*.in | バグレポートアイテム |
▲ページトップへ戻る
[ステップ2] レポートコードの決定
まず、報告されたバグについて、レポートコードを割り振ります。コードの与え方は単純でW3C-DTFの日付の書式に、最後に、同一日に複数の報告があったときのための識別コード２桁を追加したものです。2006-08-16-02 [年]-[月]-[日]-[識別コード]
となります。以降このコードを レポートコード と呼ぶことにします。
▲ページトップへ戻る
[ステップ3] バグレポートアイテムの追加
バグレポートアイテムファイルを書き、ディレクトリ、gbs/doc/xml/src/xml/bugs-reportsにセーブします。テンプレート、gbs/doc/xml/templates/bugs-reports-item.in をコピーし、利用するのが便利でしょう。 ファイル名は、[レポートコード].in
という形になります。
このファイルはトラッキングパターンにおけるitemのみを記述します。itemのcode属性には、レポートコードを与えます。titleはバグの症状を簡潔に言い表したタイトルをつけます。titleは [大まかなバグの分類](詳細な症状) といった記述になっています。例えば、
..... ]]>
というような形になります。item内部のstatusタグは、現在のバグの状況、first-reportはバグの所見、症状の説明。workaroundはワークアラウンドを書きます。その他レポートを続けて行きます。これらのタグの詳細書き方については、 [UNDEF REF (gb-manuals-tracking--item)]を参照してください。
▲ページトップへ戻る
[ステップ4] バグレポートアイテムのCVSへの追加
bugs-reportsディレクトリに追加したアイテムのファイルをCVSへコミットします。% cd gbs/doc/xml/src/xml/bugs-reports % cvs add **.in
**.inはバグレポートアイテムのファイルです。
▲ページトップへ戻る
[ステップ5] バグレポート本体ファイルの更新
新しく作ったバグレポートアイテムを本体ファイル、ja-bugs-report.xmlに追加します。このファイルは、アーキテクチャ（Windows Linuxなど）によってtrackingを分けてありますので、適切なトラッキングに追加します。 関係するアーキテクチャや項目が複数考えられる場合は、複数のトラッキングに同一のアイテムファイルを挿入してもかまいません。追加するためには、]]>
というように input文 [UNDEF REF (gb-manuals-input)]を使います。
| [注意] file属性の与え方は、srcディレクトリからのパスを書くことに注意が必要です。。 |
▲ページトップへ戻る
[ステップ6] コンパイル
マニュアルのコンパイルを実行します。これ以降はマニュアルの更新手続きの 「コンパイル」以降と同一の手順となります。% cd gbs/doc/xml % mmake
エラーが発生した場合は、エラーに対処してください。発生エラーのリファレンスは、 「mmake時エラーリファレンス」です。
▲ページトップへ戻る
[ステップ7] HTMLおよびPDFの確認
生成結果を確認します。ディレクトリ、gbs/doc/xml/man/pdf 内にPDFファイルがあります。gbs/doc/xml/man/html内にHTMLファイルがあります。これらが正しく生成されているかどうか確認します。▲ページトップへ戻る
[ステップ8] HTMLの公開
現時点では、HTMLの公開は基本的に森洋久が行います。しかし、ここで公開方法について述べます。gbs/doc/xml/man/htmlのディレクトリはCVSにコミットされているディレクトリでもあります。従って、これをそのまま公開すると、CVSという名前の制御ディレクトリまで公開されてしまいます。これを取り除く必要があります。取り除く方法は、% cd gbs/doc/xml % ./make.html.sh
という、取り除き用のスクリプト make.html.sh を実行します。これを実行すると、CVSといったディレクトリが取り除かれた公開用ディレクトリ、gbs/doc/xml/man/manが出来ます。このディレクトリを所定のWWWサーバへアップしてください。
| [メモ] GLOBALBASEの公式マニュアルページは、http://www.globalbase.org/globalbase/man/ja-index.html ですが、基本的に、このディレクトリを他の場所へアップロードすると他の場所でも公開可能です。しかしその場合検索エンジンの窓は変更しておかないと、検索結果は、かならず公式ホームページへ飛ぶことになります。 |
▲ページトップへ戻る
[ステップ9] CVSチェックイン
最後に編集したファイルをCVSへチェックインします。開発したソースコードなどがある場合は、一緒にチェックイン出来ます。% cvs commit -m "manual" gbs
| [注意] チェックイン／チェックアウトはワークエリアのルートで行う必要があります。 |
▲ページトップへ戻る
|
