Re: Proposal/CFD: bug tracking system in JP

[ISHIKAWA Mutsumi <ishikawa@linux.or.jp>]

むつみです。

＃帰りの新幹線の中から投げたら lost した模様なので
＃再度 ^^;;

>>>>> In [jp-policy : No.00217] 
>>>>>	Fumitoshi UKAI <ukai@debian.or.jp> wrote:
>> Debian JP Project での Bug Tracking System の運用に関する Proposal です。
>> あまり詳細は につめてないので、意見求む。

 おなじく、とりあえず思いつくままに。

＃新幹線の中だし(わら

>> 今は、Debian JP Project の Bug Tracking System(以下 BTS/JP)では
>> JP Package に関するバグを主にとりあつかってきました。official Debian
>> package に関しては とりあえずsubmit可能でしたが、そのreportに対して特に
>> action をおこすことは稀でした。

 そうですね。これまでの BTS/JP の位置づけは、あくまで

 ・JP Package のバグレポートをするための仕組み

でした。補助的に「JP メンバであり、かつ official メンテナである人が
メンテナンスしているパッケージ」に対するバグレポートも扱ってはいました
が、これは本来の位置づけではないように思います。

 さらに 過去 いくつか BTS/JP に official Debian package(かつ、メ
ンテナが JP のメンバではない Package)のバグレポートが飛び込んできた
こともあったように記憶していますが、この場合は「メンテナにはレポートが
行く訳じゃないよ」といったようなコメントがついた記憶はありますが、
基本的にはそのレポートは放置 ということになってまってましたよね、確か。

>> ここ最近の活動により 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 パッケージに対して 日本語でバグレポート出せる状況がある
    と、うれしいという人の絶対数が増えている(だろう)。

ということで、いいっすかね。

 で、この背景には同意します。

>> このような現状を考えると、BTS/JP の役割も以下のようにかえるのがいいと
>> 思うのですが、どうでしょうか?

>>  * 従来通り JP package の bug report はうけつける。

 JP package がある以上、これは必要っすね。

>>  * 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 をする ということですね。

>>  * 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 とかにね)のを必須としたいっす。

>> こういうことをしようとした時の考えられる疑問点としては:

>>  * 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) は なし?)

 あと、もう一点。担当者が複数ってのも「あり」ですよね?

＃ 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 的なものが必要(かな?)

>>  * debbugs-jp に必要な機能はなにか?

>>     - JP package, official package を簡単に区別できる

 これは必須ですね。えーとアプローチとしては、パッケージの db で
もげもげ っとやるのがベスト?

 そもそも submit アドレスを変えてしまうっていう手もあるかなとか思いま
したが、あんまり美しくない、かつ、BTS を受け手処理する側で区別してやる
ことになるわけで、ミスが混入する可能性がありますかね。

>>     - 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 すると 閉じるとか)
   閉じられるようなことに利用できるとうれしいかな。
   (って どう実現するよ? ^^;;)

んーー、とりあえず、こんなところで、ひとまず投げときます。

-- 
いしかわ むつみ
 <ishikawa@linux.or.jp>, <ishikawa@debian.org>, <ishikawa@redhat.com>