アカウント名:
パスワード:
>複数のバグトラッカーのバグを管理するのにどのような方法を取っているのだろうか。>特に依存するバグ同士の管理はどうするのが良いだろうか。
BTSにまだまだ詳しくないので外してたらご指南願いたいんですが、上記を読んで違和感を感じました。
「複数のバグトラッカーの」ということは主に別々のプロジェクトのという意味ですよね?一方「依存するバグ同士の」というのは主に同じプロジェクトの中のという意味ですよね?だとすればですが、なんか2つの話題がごちゃごちゃになっているのではないでしょうか?
それとも「同じプロジェクトではないが依存関係にある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的にクロールするだけか。
私の場合、もともと使っていた社内BTSと客先のBTS、両方を使わざる負えない状況なので元ネタの言いたい事はよく理解出来ます。「別々の会社」や「別々のグループ」毎に管理方法が異なるのは当然の事で、OSSでも商用プロジェクトでも普通にある事なのではないでしょうか?私のところでは結局、定期的にEXCELや箇条書きに落して、進捗報告と一緒に棚卸し結果をメール送付、その上で進捗会議で意識合わせをするといった感じです。うちの会社は下請け会社の一つに過ぎないので客先に大きな事は言えません。。
結局、バグ対処に費やす作業量のほうが大きいのであまり興味はありませんが、RSSのようにオープンで定義されたバグ表現様式が広く実装されれば効率は上がりそうですね。
>結局、バグ対処に費やす作業量のほうが大きいのであまり興味はありませんが、ですねー。
どんなバグトラッキングシステムを使ってるとか、或いは仮にExcel管理だったとしても、たった一つのスパゲッティ=プログラム、たった一人のヘボプログラマー、たった一人のコン猿やヘボ管理職の持つ破壊力に比べたら可愛いもんです。
私にはecodeタグ内の文章は本家/.のニュースが指し示している内容であると読めます。ここで誰にも読まれない長文を書いたとしても、答えるものは誰も居ないことだけは分かります。
#私ならBTSTSを作るのは骨すぎるので、投げられたメールを使ってメールベースで管理しますね。
妹が服を脱ぎ始めまで読んだ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
論点がぶれてないの? (スコア:0)
>複数のバグトラッカーのバグを管理するのにどのような方法を取っているのだろうか。
>特に依存するバグ同士の管理はどうするのが良いだろうか。
BTSにまだまだ詳しくないので外してたらご指南願いたいんですが、
上記を読んで違和感を感じました。
「複数のバグトラッカーの」ということは主に別々のプロジェクトのという意味ですよね?
一方「依存するバグ同士の」というのは主に同じプロジェクトの中のという意味ですよね?
だとすればですが、なんか2つの話題がごちゃごちゃになっているのではないでしょうか?
それとも「同じプロジェクトではないが依存関係にある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)
妹が服を脱ぎ始め
まで読んだ