Re: Proposal/CFD: bug tracking system in JP

[Fumitoshi UKAI <ukai@debian.or.jp>]

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

> >> ここ最近の活動により JP からの official member も増えてきましたし、
> >> それにともない JP package から official debian package になってものも
> >> 増えてきました。(つまり JP に残っている package は減ってきています)
> >> また元からofficial debian packageだったものでも、そのまま日本語も
> >> 使えるものも増えてきました。
> 
>  要約すると 2 点っすね。
> 
>  a-1) 本来の 「JP Package への BTS」というものは、JP パッケージが減って
>    いるので、その絶対数も減っている。
>  a-2) 逆に「日本語を利用するユーザにとって有用な official パッケージ」
>    が増えている。
> 
> で、この a-2) から導き出せるものとして、
> 
>  a-2') official パッケージに対して 日本語でバグレポート出せる状況がある
>     と、うれしいという人の絶対数が増えている(だろう)。
> 
> ということで、いいっすかね。

そうです。さらにはもっとreportをあつめて Debian そして free softwareの
quality をよくしていければいいな という感じですね。

> >>  * official debian package の bug report もうけつける(もちろん日本語で)
> >>    そのままでは単に記録に残るだけなので、official debian package に
> >>    対して JP maintainer を assign して、bug report の対応をするというの
> >>    はどうでしょうか?
> 
> >>    JP maintainer は package を build/upload はしない(*1)かわりに
> >>    package の maintainance における日本語でのユーザ対応の部分を担当する
> >>    ことになります。
> 
>  ふむ、要するに JP maintainer が (かなりヒューリスティックな解釈を
> 行う(わら) translation proxy をする ということですね。

そうですね。まぁ maintainer が upstream に bug report する時と
同じように、それなりに report された内容を理解して、自分でも
再現できるようにして自分なりの bug report としてなげれればいいですね。

> >>  * official debian package の bug report もうけつける(もちろん日本語で)
> 
>  というのは、過去にもあったらいいよね、というコメントは何度か
> 上がっていたので、実際に仕組みがうまく動くようなら、すばらしいかな :-)

まぁ 過去にあったのは単に翻訳できれば だったわけですが それだけでは
たぶん あまりやってておもしろくないと思うので :-)

> >> つまり
> >> 	- bug report を調べる
> >> 	  (必要なら submitter に聞いたり *@debian.or.jp MLで聞いたり)
> >>         - わざわざ maintainer/upstream になげるような問題でないのなら
> >>           JP内で解決する
> >>         - package をなおさないといけないのは BTS へ submit
> >> 	- official maintainer/upstream と どのように解決するかを相談したり
> >>         - official maintainer/upstream に patch を送ったり
> 	  
> >>         (*1)場合によっては NMU もありえますね。
> 
> >>    あたりを user に対しては maintainer の気持ちで、maintainer に対しては
> >>    user の気持ちで 対応するという感じでしょうか。	  
> >>         (*1)場合によっては NMU もありえますね。
> 
>  仕組みとしては理解。おそらく、考えるにこの形態が妥当(というかこうい
> うやり方しかない?)と思います。
> 
> >> # もちろん、英語のcommunicationができるユーザは 直接やりとりするのを
> >> # 推奨すべきですが (日本にもユーザはたくさんいるんだぞ というのを示すためにも)
> 
>  そう思います。ということで、このシステムが稼働し始めた場合には、この
> 点に関して注意を盛り込む(Web とかにね)のを必須としたいっす。

BTS/JPの 自動応答にそういうメッセージをいれておけばいいですかね。
 
> >> こういうことをしようとした時の考えられる疑問点としては:
> 
> >>  * JP maintainer は誰がどれをやるのか?
> 
> >>     - official maintainer が JP member ならその人が担当
> 
>  まぁ これは そうでしょうね。間に人が入っても話がややこしくなったり
> するだけでしょうし。
> 
> ＃あぁ でも 間に人が入ってくれて フィルタしてくれるとうれしかったり
> ＃することもあるかも? (わら
> 
> >>     - それ以外は 基本的に package の maintainer と同じように volunteer で
> >>       やりたい package を担当するのでいいんじゃないでしょうか?
> >>       自分でよく使ってる package ならそれなりに対応もできるでしょうし。
> >>       (例: XFree86 なら むっち とか:)
> >>       section単位とか、official maintainer単位というのもアリかも?
> 
> ＃うへ ^^;; その例は Branden のお守り or DIEと言いたい?(わら
> 
>  えーと これ 担当しますと手を挙げるのは「いつ」でしょう?
> 
>  考えられるのは、以下かな。排他ではないので、おそらくこれらの
> いくつかの組み合わせもあるっすかね。
> 
>  b-1) この仕組みを運用する前に あらかじめ、ある程度固定して
>    パッケージごと(あるいは、section単位とか、official maintainer単位)
>    で、担当を決めておく
> 
>  b-2) BTS が行われた時点 or 新規のパッケージが upload された時点で、
>    それに対して adapt する(wnpp の orphan & adopt システムを応用できる
>    かも? BTS & adapt)。以後、そのパッケージはその人が担当。
> 
>  b-3) バグレポートごとに担当者を決める(adapt する)。パッケージに担当者を
>    固定するのではなく、バグレポートに対して担当者を固定する。
> 
>  Debian の package maintainer policy があるパッケージに対して担当者を
> 固定する方式なので、b-3) はちょっと親和性が低いかという気がしますね、
> それに レポートごとの関連を追いにくくなるし。
> 
>  b-1) b-2) の併用でしょうか。

そうですねぇ
 
> 　b-2) について、いつ adapt するかといるかというタイミングですが、
> 新規パッケージの upload があったとき(から随時)という形がいいんじゃない
> かと思われます。BTS されてから担当を決めるとなると、そのdelayが、ちと
> 問題かなと。
> 
>  c-2)の場合、バグに対して迅速な行動を起こせない可能性が考えられるので、
> c-1)の方がいいという気がしますね。(ってことは b-2) は なし?)

c-1,c-2 って下のやつ?
 
>  あと、もう一点。担当者が複数ってのも「あり」ですよね?

まぁ アリでしょう。担当者間でもめたりすると困りますが:)
 
> ＃ X とか一人でやると死の予感が ^^;;;
> 
> >>     - 担当者がいないのは -qa 的チームがあつかう とか?
> 
>  えーと、少なくともバグが報告された場合、迅速な対応が必要になることが
> 多々あるので、担当者がいなくても動けるというのは重要でしょう。
>  あと、おそらく パッケージ数が現時点相当数ありますから、全てのパッケー
> ジに対して、担当者が決まるとは 到底思えないので、よろず引き受けチーム
> は必要かなと思います。
> 
>  えーと、まとめると 次のような感じかな。
> 
>  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 重構造にしとけばいいのかな?概念的
> には。
> 
> (って、ここまで書いて京都に着いたので降りて、今まで はったさん、
> まえはらさん、のくびさん、えせざこば師匠、(まちの＠vine さん)
> と話してきましたが、うかいさんが最初に言ってたのは、↓こういうことね)
> 
>  この概念を拡張して、他の地域たとえば 中国とか韓国とか ある地域ごとに
> 同様の仕組みを構築して機能させることができれな、そのパッケージの
> official mainatiner とそれをサポートする regional maintainer (って呼び
> 方でいいかな?)的階層構造ができて bug report と その fix に対する負荷分
> 散がはかれる可能性があるということになるわけですね。

まぁ そうです。
 
>  とりあえず、概念的にはかなりすっきりしてますし、あとは細かい実装
> の部分を詰めていけば OK な気がします。
> 
>  以下、運用上の疑問点。
> 
>  - ここで言っている JP maintainer とは、だれ(どの)集合をさすか?
>    要するに、あるパッケージの責任者(regional maintainer )になれ
>    る(なることが可能、なる資格がある、ならなければならない)のは
>    だれなのか?
> 
>  - qa チームの構成は?

これは もうちょっとつめてから始めた方がよさそうですね。
 
>  - BTS 以外に wnpp の db 的なものが必要(かな?)

wnpp は今はもう BTS でやってますよね?
まぁ BTS/JPやるんなら RFP くらいですかね?

> >>  * debbugs-jp に必要な機能はなにか?
> 
> >>     - JP package, official package を簡単に区別できる
> 
>  これは必須ですね。えーとアプローチとしては、パッケージの db で
> もげもげ っとやるのがベスト?
> 
>  そもそも submit アドレスを変えてしまうっていう手もあるかなとか思いま
> したが、あんまり美しくない、かつ、BTS を受け手処理する側で区別してやる
> ことになるわけで、ミスが混入する可能性がありますかね。

あとありがちなミスとしては nnnn@bugs.debian.org に出そうとして
nnnn@bugs.debian.or.jp に出してしまった(もしくはその逆)ってのが
あるので それをうまくあつかいたいところですねぇ。
# JPの方は nnnn-jp@bugs.debian.or.jp として localpart が数字だけ(かつ
# US-ASCIIだけ)だったら org の方に forward とかでいいのかな
 
> >>     - official package bug の page http://bugs.debian.or.jp/<package>は 
> >>       http://bugs.debian.org/<package> へのリンクがあると good
> 
> >>     - debbugs にある機能に加えて BTS に投げた時の bug への link などが
> >>       自動的に 追従して欲しい。
> 
>  ふむ。
> 
>  - JP/BTS と official BTS 間の関係を DB 中で持ちたい。
>    ある official BTS が閉じられると、自動的に(あるいは半自動? 例えば
>    JP/BTS の責任者に対してメールが飛んで、confirm すると 閉じるとか)
>    閉じられるようなことに利用できるとうれしいかな。
>    (って どう実現するよ? ^^;;)

BTSからそれらのメールは そういうMLになげられているので
そのメールをうけて 処理するとかかなぁ

-- 
鵜飼文敏 at MountainView CA, USA