複数のバグトラッカーのバグ、どうやって管理している？ 30
ストーリー by hylom
重大なもの以外は放置、たまってきたらお掃除、 部門より
重大なもの以外は放置、たまってきたらお掃除、 部門より
あるAnonymous Coward 曰く、
本家「How To Track the Bug-Trackers?」より。
バグをレポートし、レスなどを待つというのは開発者にとってもユーザにとってもスタンダードオペレーションとなっていると思う。どのプロジェクトもbugzillaやtrac、メーリングリストなどをバグトラッカーとして使っている。タレコミ人の場合、最多40程のOSSプロジェクトにまたがる200以上のバグをトラックしている。
バグの半分くらいは他のバグフィックス依存で、バグごとにスレッド等がある状態だ。マネージメントに進捗を聞かれ、慌てて放置されていたバグに手をつけ始めるなんていうのもよく見る光景だ。/.の皆は複数のバグトラッカーのバグを管理するのにどのような方法を取っているのだろうか。特に依存するバグ同士の管理はどうするのが良いだろうか。このタレコミ主は使用不能になった32インチTV（もちろん光沢でツヤツヤのスクリーン！）にポストイットを貼るという方法を使っているそうだ。また、タグに「penandpaper」とあるようにアナログ管理もオススメされている模様。
おっと！ (スコア:2, おもしろおかしい)
ここ数週間、見るのをまったく忘れていた。
（まだ内部利用だけで公開してるわけでないから大したことないけどね。）
バグの相互依存 (スコア:2, おもしろおかしい)
> バグの半分くらいは他のバグフィックス依存で
Ａ「Ｂのバグが直らないと、このバグ取れないんすよー」
Ｂ「そのバグはＡのこのバグに依存してるんすよー」
Ａ「そのバグはＢのこのバグから派生してるんすよー」
Ｂ「そのバグはＡのこの・・・・」
これをバグの「デッドロック問題」と言う。
バグフィックスのデレゲーション (スコア:1)
AとBの両者でタライ回してはいるけど、個々のバグレベルでは依存関係がループしているようではないので、高々有限回で始祖バグにたどり着ける気がするからデッドロックではないような。
Re:バグフィックスのデレゲーション (スコア:3, 参考になる)
＞AとBの両者でタライ回してはいるけど、個々のバグレベルでは依存関係がループしているようではないので、
＞高々有限回で始祖バグにたどり着ける気がするからデッドロックではないような。
仕様のデッドロックである可能性がある。
その場合、双方の歩み寄りが必要です。
Re: (スコア:0)
>仕様のデッドロックである可能性がある。
仕様のデッドロックの原因が複数組織や部署間の足の引っ張り合いの場合は、
一体いかがすればいいんでしょ？
Re: (スコア:0)
何を使うのがいいんでしょうね？ (スコア:1)
ウチはPukiWikiのbugtrack。
やらないよりはいいかと思って使ってるが、微妙な使い勝手。
ところで外人混じりのチームなんで英語で書くようにしてたら報告者には敷居が高いらしい。
といって、日本語で書くと外国人が「読み飛ばす」率が上がる。どうしたものでしょうかね。
今は未公開でトラフィックも少ないので時々訳してるが、今後増えたらいちいち英訳もしてられないしなぁ。
Re:何を使うのがいいんでしょうね？ (スコア:1, 興味深い)
長年複数の会社のβテスター（ていうかソフトだけタダでもらえる割りに合わないボランティアｗ）をしてますが、
日本語だとかなりあいまいになっちゃって、カタカナ混じってわかんない文章になりがちですが、
英語だと同じこと書いてもクリアーです。前後関係がはっきりしますし、時間的な順番とかも狂わないですし、
否定も肯定もはっきりしますし、指示代名詞を変数みたいに使えますし、英語ってこういうとこすごく便利だなと思います。
もともと英文書くのはそんなに得意じゃなかったんですがやってるうちにバグ報告だけは出来るようになってきました。
Re:何を使うのがいいんでしょうね？ (スコア:1)
そすかね？
私の英語コメントはJokeでもないのに時々職場の仏人の若者にケケケと忍び笑いを漏らさせるんですが。
日本語ならそういうことはないんですけどねぇ。
Re:何を使うのがいいんでしょうね？ (スコア:1, 興味深い)
それは、読書やヒアリング量が足りなくて表現力が乏しいからそう思えるだけ。
日本の英語教育は文法重視に偏っているので、自然と杓子定規なお堅い文章になる。
英語ネイティブの英語はやっぱり、日本人の日本語のように曖昧でぐちゃぐちゃだよ。
＃ただ、向こうは学校できちんとテクニカルライティングの授業を受けるので、
＃きちんと教育を受けた集団同士で比べると、論理的な文章を書ける人の割合は日本人より多い
Re: (スコア:0)
>それは、読書やヒアリング量が足りなくて表現力が乏しいからそう思えるだけ。
>日本の英語教育は文法重視に偏っているので、自然と杓子定規なお堅い文章になる。
>英語ネイティブの英語はやっぱり、日本人の日本語のように曖昧でぐちゃぐちゃだよ。
これは訳わかんない返答ですね、
もとの文章の文意が伝わりませんでしたね、英語だったら通じたんでしょうか。
日本語は難しいよ。
Re: (スコア:0)
日本語が曖昧なのではなく、貴方の書く日本語が曖昧なだけですよ。
もっと努力しましょう。日本語を母国語で使うつもりならば。
Re: (スコア:0)
>日本語が曖昧なのではなく、貴方の書く日本語が曖昧なだけですよ。
「指摘を明確にすることが相手を傷つけるかもしれない」と言う意味のない配慮をしているせいだと思います。
明瞭に書くことと2ch並に罵倒することは明らかに違うのですが明瞭に書こうとして簡潔に済ませすぎると機微を大切にしている普段の表現から逸脱するために恐れが生まれるのではないかと考えます。
私は明らかにそういう配慮をした時期がありました。
Re: (スコア:0)
日本人側は明瞭かつ簡素に書いてるだけのつもりだったが英語圏の人間から見ると慇懃無礼な表現になっていて、
しかも英語があまり得意で無い人達は他人が書いたバグシートをテンプレ的にコピペして使う傾向があって、
結果その種の表現が蔓延してしまい、えらく険悪な雰囲気になって困ったことがあります。
では (スコア:1)
Re: (スコア:0)
了解しました。RedMineについてはmokoakiさんに聞け！ってことですね。
何がアドバンテージですか？使いやすいですか？
GUIメインですか？CUIでも使えますか？
スタンドアロンでもOKですか？
赤いですか？3倍速いですか？
Re:では (スコア:1, 参考になる)
中身は全く知りませんが、書籍が出てるよ、ということだけは知っています。
http://www.cbook24.com/shop/productdetail.aspx?sku=9784798021379 [cbook24.com]
うーん、お題目にはWindows対応って書いてるようだけど、
中にWindows(で鯖立てる話)が載っていただろうか？
Tracを普段使ってる(＆使わさせられてる)身としては、
複数プロジェクト対応、
特にチケットをプロジェクト「間」で移動できるって機能は
うらやましいと思った。
ただ、単数プロジェクトしかサポートしないBTSであっても、
InterWikiNameならぬ「InterBtsName」機能なんてのを持っていれば、
ほかのBTSインスタンスと疎結合できるんじゃないか？とも思った。
あとデフォでガントチャートがついてるのも少し羨ましかったが、
そもそもガントチャートという管理ツール自体に疑問を感じるんで、べつにいいか。
外部のバージョン管理ツールと連携できるのも裏山鹿だが、
これはTracの仕様(SVNリポジトリをTrac鯖ローカルに持って直アクセスしてるようだ)がヤバすぎるだけ。
なおRedMineの話からは離れるが、
同書のBTS運用ベストプラクティス(のうちRM非依存の部分)は
結構参考になるなあと思って読んだ。
結構良いこと書いてます。
もっとも今の仕事で変則的(かつ硬直で変更困難)なBTS運用をやらされてるぶんには、
その知恵の１％ですら流用できなさそうだ。
結局はユーザというか管理主権者(社)の能力次第なんだよね。
ふつうの想像の斜め45度上をいくような馬鹿運用をされてしまうと、
どんな優れたツールもゴミと化してしまう。
Re: (スコア:0)
あくまで伝聞。
>GUIメインですか？CUIでも使えますか？
Tracとくらべて、いわゆるWebベースで設定が全部できるのが売りらしい。CUIという方向とは逆だけど。
どうしても気になるならw3mで設定やったらどうだろう？動くかどうか(つまりJavaSc必須ではないかどうか)は未確認。
>スタンドアロンでもOKですか？
Tracと違って(SVNとのあいだが)分散でもOKのが売りらしい。むろんスタンドアロンでもいいのだろう。
>赤いですか？3倍速いですか？
RubyOnRails製らしい。
処理速度は知らん。TracもPythonなわけだからどちらもCゴリゴリなアプリほどの速度は望めまい。
個人的には
Re: (スコア:0)
Re: (スコア:0)
>会社で使うと担当者によって登録単位がばんらばら
それでいいんじゃないでしょうかね、「当初は」。
ツール導入も永遠のベータ版というか、
複数のチームで勝手な使い方で使ってみる、という気楽なところ「から始める」といいんじゃないかと思っています。
そして、しばらくしたら(というか以後定期的に)、チーム間で交流会をするんですよ。
「うちはこう使った」「ここはこうのほうがいいんじゃないの」などといった情報を互いにフィードバックするんです。
(ここで「チーム間に競争心から秘密主義が」なんてなこと言うチームは、
同じ会社に居る価値が無いんだから、チーム単位で分社しち
日本語がおかしい (スコア:0)
バグトラッカーソフトのバグの管理なのか
バグトラッカーにリストされているバグの管理なのか
Re: (スコア:0)
Re:日本語がおかしい (スコア:1)
文章指摘のコメントって不毛だとは若干感じつつ……
両方だと思います。日本語のタイトルを補完するなら「複数のバグトラッカーの複数のバグ」でしょう。英文では複数なのはBTSですが、一つのBTSのバグが一つだけって状況は一般的でないですし。
#あああ、やっぱり不毛だ。読んでる人、すいません。
LIVE-GON(リベゴン)
優先順位付キュー (スコア:0)
バグ管理システムは、会社ではMantisを使ってます。
論点がぶれてないの？ (スコア:0)
＞複数のバグトラッカーのバグを管理するのにどのような方法を取っているのだろうか。
＞特に依存するバグ同士の管理はどうするのが良いだろうか。
BTSにまだまだ詳しくないので外してたらご指南願いたいんですが、
上記を読んで違和感を感じました。
「複数のバグトラッカーの」ということは主に別々のプロジェクトのという意味ですよね？
一方「依存するバグ同士の」というのは主に同じプロジェクトの中のという意味ですよね？
だとすればですが、なんか2つの話題がごちゃごちゃになっているのではないでしょうか？
それとも「同じプロジェクトではないが依存関係にある２つのプロジェクト」の話なのでしょうか？
----
ところで上記の疑問(ないしは無知)はともかくとして、
「依存するバグ同士」についてですが、やはりここは、
●バグチケットというノード(点)
●チケット間を繋ぐエッジ(線)
という二種類のデータを持つような構造にするのがいいんじゃないでしょうか？
つまり任意のバグのあいだを繋ぐ線を引ける、というデータ構造(およびそれを扱えるUI)のうえに
BTSを構築するというか。
ERふうにいえばノードがリソース系、エッジがイベント系で交差エンティティ※によって実装する、といったところか？
※多対多結合を主目的とするテーブル…という理解でいいのかな。テーブル実装としては、AおよびBというノード(テーブル)が有るとして、それの間をつなぐ交差なテーブルCは、AのPKとBのPKを持つ(かつそれらをCのPKとする)ようなテーブルになるんだそうですね。
で、BTSサイトという1つの器の「なか」にバグチケットをためる方法はスケーラビリティ(今回の話のように別プロジェクトとの繋がりとか…)に欠ける恐れが有ると思います。だから極論すれば、バグチケットノードのURLがネットワーク上に晒されていて、そのノード間を繋ぐ交差エッジのURLも晒されていて、リンクで辿っていける、というオープン型の構造にしちゃえばいいんじゃないだろうか？分散バージョン管理ならぬ分散BTSとでもいうか。繋がりを全部一覧するにはGoogleのようなWeb検索エンジンに頼ることになりますが:-)
そういや交差エンティティ的なものをRESTful URLで表現しようとしたら、どうしたらいいのだろう？RESTなURLはパスの階層的な構造がDBでいうPK情報(=一意性)を旨く表現してるけど、交差だと「よその2つのPKの組み合わせが自分のPK」なのでURLにマップしにくい。それとも交差にも自分用のPKを与え、自分のなかのデータとしてヨソの2つのURLを持てばいいのかな？まー元々「2つ以上のページへのリンクを持つページ」は交差エンティティみたいなもんだからなあ。あとはGoogle的にクロールするだけか。
Re:論点がぶれてないの？ (スコア:1)
私の場合、もともと使っていた社内BTSと客先のBTS、両方を使わざる負えない状況なので元ネタの言いたい事はよく理解出来ます。
「別々の会社」や「別々のグループ」毎に管理方法が異なるのは当然の事で、OSSでも商用プロジェクトでも普通にある事なのではないでしょうか？
私のところでは結局、定期的にEXCELや箇条書きに落して、進捗報告と一緒に棚卸し結果をメール送付、その上で進捗会議で意識合わせをするといった感じです。
うちの会社は下請け会社の一つに過ぎないので客先に大きな事は言えません。。
結局、バグ対処に費やす作業量のほうが大きいのであまり興味はありませんが、
RSSのようにオープンで定義されたバグ表現様式が広く実装されれば効率は上がりそうですね。
Re:論点がぶれてないの？ (スコア:1)
＞結局、バグ対処に費やす作業量のほうが大きいのであまり興味はありませんが、
ですねー。
どんなバグトラッキングシステムを使ってるとか、或いは仮にExcel管理だったとしても、
たった一つのスパゲッティ=プログラム、たった一人のヘボプログラマー、たった一人の
コン猿やヘボ管理職の持つ破壊力に比べたら可愛いもんです。
Re: (スコア:0)
私にはecodeタグ内の文章は本家/.のニュースが指し示している内容であると読めます。ここで誰にも読まれない長文を書いたとしても、答えるものは誰も居ないことだけは分かります。
＃私ならBTSTSを作るのは骨すぎるので、投げられたメールを使ってメールベースで管理しますね。
Re: (スコア:0)
妹が服を脱ぎ始め
まで読んだ