Re: Proposal/CFD: bug tracking system in JP

[Taketoshi Sano <kgh12351@nifty.ne.jp>]

佐野＠浜松です。

In <87r92dcem0.wl@lichee.ukai.org>,
 on "Tue, 09 Jan 2001 17:29:58 +0900",
  Fumitoshi UKAI <ukai@debian.or.jp> さん wrote:

> At Sun, 07 Jan 2001 04:15:04 +0900,
> ISHIKAWA Mutsumi <ishikawa@linux.or.jp> wrote:

> >  えーと これ 担当しますと手を挙げるのは「いつ」でしょう?
> > 
> >  考えられるのは、以下かな。排他ではないので、おそらくこれらの
> > いくつかの組み合わせもあるっすかね。
> > 
> >  b-1) この仕組みを運用する前に あらかじめ、ある程度固定して
> >    パッケージごと(あるいは、section単位とか、official maintainer単位)
> >    で、担当を決めておく
> > 
> >  b-2) BTS が行われた時点 or 新規のパッケージが upload された時点で、
> >    それに対して adapt する(wnpp の orphan & adopt システムを応用できる
> >    かも? BTS & adapt)。以後、そのパッケージはその人が担当。
> > 
> >  b-3) バグレポートごとに担当者を決める(adapt する)。パッケージに担当者を
> >    固定するのではなく、バグレポートに対して担当者を固定する。

そういえばこれを読んでふと思い出したのですが、以前 Debian の NM team で
申請を管理するデータベースとかどうやってやるんだ、って話題の時に紹介されて
いた webrt パッケージみたいな "Trouble Ticket System" というものもありますね。

まあせっかく BTS があるので、それベースでやれるならそのほうがいいんだろうけど。

> >  Debian の package maintainer policy があるパッケージに対して担当者を
> > 固定する方式なので、b-3) はちょっと親和性が低いかという気がしますね、
> > それに レポートごとの関連を追いにくくなるし。
> > 
> >  b-1) b-2) の併用でしょうか。
> 
> そうですねぇ

> > >>     - 担当者がいないのは -qa 的チームがあつかう とか?
> > 
> >  えーと、少なくともバグが報告された場合、迅速な対応が必要になることが
> > 多々あるので、担当者がいなくても動けるというのは重要でしょう。
> >  あと、おそらく パッケージ数が現時点相当数ありますから、全てのパッケー
> > ジに対して、担当者が決まるとは 到底思えないので、よろず引き受けチーム
> > は必要かなと思います。

「よろず引き受けチーム」の活動を考えると、上記 b-3 の「レポートごとに担当」
という場合は必ず出てくるだろうと思われます。

そういう場合は NM team で AM が applicant を担当するような感じで、
複数の BTS 運用メンテナ (BTS システム/パッケージの開発メンテナ
じゃなくて) の中から個別の report に対して担当を割り当てていく
ような運用が必要になってくるんじゃないかな。

# そういや、「BTS の運用メンテナは必要じゃないのか ?」って話、
# 以前に聞いたことがあったな。
# 
# > I have a question about BTS; are there any BTS housekeepers, who
# > detect such forgotten reports and do some treatments? If there are,
# > maybe it's not your job; it belongs to housekeepers.
# > (Maybe BTS administrators who maintain BTS in a "software system" point
# > of view, but housekeeping procedure may be not a procedure of
# > administrators.  We usually two types of maintainers in Web system; one
# > is for web server, and another is for web contents. There is no reason
# > that BTS also have two types of maintainers.)
# 
# まあ Debian でも QA team はいろいろ苦労してるみたいだしなぁ
# (Adrian がちょっと前にキレてたっけ)

> >  えーと、まとめると 次のような感じかな。
> > 
> >  c-0) 運用前にある程度 担当者が確定できる部分は決めておく。
> >      - JP にいる official maintainer の分
> >      - 事前 adopt (前述 b-1)
> > 
> >  c-1) 新規のパッケージの upload があると、そのパッケージに関しては
> >      とりあえず -qa 的 チームに 割り当て。担当者の名乗りがあった場合
> >      -qa 的チームから その人へ担当者を交代。
> >      逆もあるか。担当をおりた場合、-qa チームが引き取り。
> >      複数から名乗りがあった場合は?
> > 
> >  c-2) JP/BTS に登録があると、担当者へ連絡。
> > 
> >  c-3) 担当者 必要な対処(upstream/oficcial への連絡などなどなど)をする
> > 
> >  c-4) fix されたら JP/BTS を担当者が close
> > 
> > って書いてて思ったけど、これって official の パッケージメンテナンスの
> > 構造をそのまま持ってきて、JP との 2 重構造にしとけばいいのかな?概念的
> > には。

> >  この概念を拡張して、他の地域たとえば 中国とか韓国とか ある地域ごとに
> > 同様の仕組みを構築して機能させることができれば、そのパッケージの
> > official mainatiner とそれをサポートする regional maintainer (って呼び
> > 方でいいかな?)的階層構造ができて bug report と その fix に対する負荷分
> > 散がはかれる可能性があるということになるわけですね。
> 
> まぁ そうです。

趣旨はなんとなくわかったような気がしますが、今までの話にあまり反応が
無さそうなところから見て (みんなここは読んでないのか ?) 果たして作業
する人が集まってくれるのかどうか不安だったり。

「負荷分散」できるほとのパワーがあればいいけれど、レポートだけ集めて
対応が追いつかずに死蔵してたりするとかえってマイナスになったりしない
かな、とか。

やるなら QA team に最低でも 10人くらいは、それなりに動ける人が欲しい
ですね。宣伝が必要だな。announce に流したりとかして人集めしないと。

現状だと例えば JP の users ML である問題が報告されたりすると、その時に
関心を持った人や同様な問題で苦労してる人がいればそこで現象を確認できて、
さらにたまたま英語で bug report 書ける人がその中にいれば Debian の BTS に
 submit して、という流れがあったりしますよね。

で、そういう、今まで users ML に参加して、報告された現象を確認したり
 bugreport 書いたりしてくれていた人達が一緒に作業してくれるように
なるのだったら、「負荷分散」も夢ではないかな、という気もしますが、
「たまたま自分が苦労してる問題が ML で話題になったから参加してみた」
というようなノリだと気軽にやってみることができても、「バグ担当」と
して報告がきたらいつでも受けなきゃいけない、というプレッシャーが
あったりするとなかなか「はいやります」とは言えなかったりする、という
ようなこともあったりするんじゃなかろうか、と思ったり。


まあなんにしても他の人から意見が出ないところが気になりますね。

--
     ＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
    <kgh12351@nifty.ne.jp> : Taketoshi Sano (佐野　武俊)