[% title = "Debian バグ追跡システムの効果的な利用法" %]
Debian バグ追跡システムの効果的な利用法
(page 1)
バグ追跡システムとは何か
Bug Tracking System (BTS)
「バグを追いかけて逃さないようにする」
忘却(oblivion)や混同(confusion)を阻止
バグというリスクの管理
品質保証(Quality Assurance)の中枢
プロジェクトのインフラ
(page 2)
バグ追跡の流れ
ユーザから
- ユーザからメールでバグ報告を受け取る
- 記録(番号付け、重要度)してメンテナにバグ報告を転送
- ウェブで閲覧可能にする
- (他の)ユーザからの追加情報受け付け
メンテナから
- メンテナから修正完了メールを受け付ける
- ユーザへバグ修正完了を報告
- 問題解決後も情報として閲覧可能
(page 3)
バグ追跡システムの種類
Debian では debbugs が使われている
実績豊富(最近100000件突破)
Debian JP では debbugs-jp
同種のものとして
- GNATS(GNU)
- Bugzilla(Mozilla)
- Jitterbug(Samba)
などがある
(page 4)
バグ追跡システムの意義(1)
特別な知識が無くても Debian 開発に参加できる
ユーザとメンテナの(おそらくは)唯一の接点
Debian の「サポート窓口」
(page 5)
バグ追跡システムの意義(2)
情報の共有
ノウハウ、ナリッジベースの蓄積
オープンソース界全体の「共有財産」
ネットワークの外部性
(page 6)
debbugs の問題点
原則英語を使用
リクエストサーバ(request@bugs.debian.org)
(page 7)
フロントエンド(1)
自分で一から書いても良いが...
フロントエンドは
- (関連)パッケージのバージョンと依存情報
- システム全般の情報
といった重要な情報を収集してメールにしてくれる
メンテナもユーザも助かる
(page 8)
フロントエンド(2)
bug(bug-ja)
reportbug
- 現在の標準的フロントエンド
- 使いやすい
- 豊富な機能
- コンソールベースなのが長所でもあり短所
- わりとおすすめ
(page 9)
フロントエンド(3)
debbugs-el
- Mew、Wanderlustといった Emacs 上の MUA と連携可能
- おすすめ
(page 10)
実演
(page 11)
報告する前に
すでに報告されていないか確かめよう
メンテナの心証を悪くしないように
- Severity くらいはきちんと設定しよう
- できるだけパッチ、それもきれいに当たるやつを送ろう
- diff -urN
(page 12)
英語について
日本語で簡潔に書いてみる
箇条書き
主観を入れるな
客観的事象のみを記述
漢ならコードで語れ
(page 13)
まとめ
もっと文句を言おう
圧力団体になってごねよう
言わないと Debian は一向に良くなりません
(page 14)