[debian-users:26597] Re: 御意見募集 : JP BTS について

[ISHIKAWA Mutsumi <ishikawa@xxxxxxxxxxx>]

むつみです。

>>>>> In [debian-users : No.26595] 
>>>>>	fsawa@xxxxxxxxxxxxxxx wrote:
>> 古澤です。

>> > Debian JP の佐野です。
>> > 
>> > 先日から jp-policy ML で Debian JP Project の BTS について、
>> > 運営方針を変更すべきかどうかという議論が行なわれています。
>> > 
>> >  (<http://lists.debian.or.jp/jp-policy/200101/> 参照)

>>   上記の提案は bug fix の負荷分散(単位は国?)と、 日本語圏内における
>> bug 報告の促進が目的ということですよね。

 簡単に言うとそうですね。

 日本語で (JP のではなく) Debian の official パッケージに対して
バグレポートできたら嬉しい

という意見が過去何度かあったし、まぁ 需要は少なからず存在するだろうと
予測できるので、これを実現するにはどうやるよ? というのが話のベースに
あります。

 で、やり方を詰めてみた結果、BTS のスケーリングと地域メンテナ という
概念「も」見えてきた ということです。

 で、技術的な視点からは、後者がおもろそうなので、そっちに目がいって
しまいがちなのですが(わら そもそもの 大きな目的は「日本語で BTS できる
こと」だと思います。

 で、後者「地域メンテナという概念とBTSのスケーリング」という目的に
関しては、たぶんに実験的な要素を含んでいる(そもそも、うまく機能するの
か? 需要があるのか? とか)と、考えています。

>>   この目的に反対する理由は全くないのですが、意見をもとめられても users 
>> な人間(devel に参加していない)の立場からすると反応しにくいと思います。

>>   というのは実際にメインテナとして作業を体験していない私のようなusers 
>> の人間にとって(ひとくくりにするのもなんですが)、提案のような全体の負荷
>> 総量より平均負荷をさげるようなシステムの変更に伴う、中間に立つ JP のメ
>> インテナの方々の負担がどの程度増えるのか、またその効果を判断しかねるか
>> らです。

 それは、メンテナやってる人にとっても、おそらくさっぱり
わからないと思います(わら

 非常に予想しづらいです。

 さきほども言いましたが、これはたぶんに実験的要素も含んだ試みなので、
問題があるようなら、修正 or 廃棄(やめやめ、あかんわ これじゃ)という
判断になることも十分考えられるでしょう。

>> JP メインテナの方々の中からこのような案がでてくるからにはきっと具体的な
>> 解決策が前提にあると思うのですが、たとえば以下のようなことが気になりました。

 えーと、いま書きましたが 実際にやってみないと問題点が見えないだろうと
いうのがあるし、やりながら修正でも ええやんという 感じだったりします。
(すくなくとも、おれの中では)

 ただ、Debian JP Project に参加してる人は、それなりの人数が居るのと、
Debian Official Developper に登録されている人もかなり増えたので、頭数
的にはどうにかなるだろうという、楽観的な予想に基づいてたりしますが(わら

>>   ・ Debian パッケージは数千あって、中間メインテナはその全てに対応する
>>   可能性があるがそれは果たして可能なのか、そしてその役割の分担方法は？

 えーと、まず ハンドリングできないほど大量のバグレポートが飛び込んでく
るかね? ってのが、あったりしますね ^^;;

 で役割分担ですが、前述の URL から、スレッドの最初の方を読んでもらえれ
ばいくつか案が出てるますが、具体的に決めた段階ではありません。

 1) Debian JP かつ Debian Official なメンバーな場合は、その人
 2) それ以外 のパッケージは各自のチョイスで得意/必要な物を
   たとえば、jtex とかメンテナンスしてれば、必然的に tetex パッケージ
   とか、そっちも見ないといかんだろうから、関係するパッケージとかも
   担当してくれるとうれしい
 3) でもって、あとは やりたいもの
 4) QA チーム(的)を編成しておき、担当がないものに対してのリポートは
   そのメンバーが担当
 5) その他、単発で「このバグレポートは私が処理するっす」というのもアリ。

とかでしょうか?

>>   ・バグトラッキングシステムの途中経過、クローズ報告を本家と連動させるのか？

 「システム的に連動できるようにするのが、最終的にはよい」のでしょうが、
いきなりそのシステムを構築するのは不可能なので、当初は「人手により可能
な部分は連動させましょう」ということになるでしょう。

＃そのためのいくつかシステムの拡張が必要かも?

 たとえば、

 1) ある人から JP BTS に日本語で報告があった
 2) そのパッケージ担当は、それに対してアクションをおこす。
   - 状況がわからなかったりするなら、報告者などから より詳しい情報を聞
     き出したりする
   - 本当にバグなのか判断する(不必要な バグレポートのフィルタリング)
   - 必要なら Debian BTS や Upstream に報告(Cc: JP BTS しとけば、それ
     も記録に残るよね?)
   - 余裕があれば、パッチ書いたりすると、なおよかったりもする

 3) Official BTS で バグがクローズされたり、なんらかの対処が行われたら、
   JP BTS にも反映する。

どちらかというと、テクニカルな作業より、バグ報告者との間、および、
メンテナとの間のインタラクションの方が多くなるものと思われます。

>> さてこれは後者の問題について提案です：
>> ================================================================

>>   JPパッケージでないバグ報告については、本家とJPでフル装備の BTS を二
>> 重に走らせるのは大変なので、中間BTS(JP) には中間メインテナの行った
>> 作業のみを書く。

 えーと、実際に Debian の BTS の様子をみてもらえればわかりますが、
多くがバグ報告者とのやりとりの記録です。で、これは メールベースで行わ
れるので、単純に Cc: などを利用して JP BTS にもメールが飛ぶようにすれ
ば記録が残せることになるわけで、さほど大きな負荷にはなり得ません。

>>   バグがJPに報告される-> JP メインテナの判断や行動(棄却しました or
>>                                                     patch を作成し
>>                                                     本メインテナに
>>                                                     投げました、など)

 これに関しては BTS 本体の記録じゃなくて、BTS 上の状態記録(open, close,
forwarded などなどなど)を利用するのがよいかと思います。

＃そのために、いくつかの状態を拡張するひつようがある?

>>   本家でのクローズやその過程を追い反映するのは負担大なので一切行わない、

 この負荷も大きくありません。というより、BTS に報告をつっこむと、それ
以後、そのバグが close されるまで、BTS を利用したやりとりは報告した人
にも 全てメールが行くようになってますから、届けられるメールに目を通す
だけです。

 従って、来たメールに対して、適切なアクションを起こす(JP BTS へ
 control メールを投げるとか、JP BTS の報告者へ質問を戻すとか)のが
大きな役割であって、ここをいっさい行わないのは、そもそも この提案を
否定しているようなものです。

>> 必須な記録はバグが報告されたことと、中間メインテナが起こしたアクションのみ。
>> その他の状態(バグがクローズされたのかどうかなど)は本家 BTS に任せる。

 クローズされたというメールが来たら、一通 JP BTS にメールを出すだけで
JP BTS への報告がクローズできるわけですが、これが大きな負荷となると
思われますか?

 それから、クローズせずにほっておくということは、結局 その問題が
実際に解決したのかどうかを JP BTS の状態を見ただけでは判断できないわけ
で、BTS の意味が半減する物だとおもわれます。

>> 主旨：  「言語の璧が問題となってバグ報告が渋られるような事態を防止すること」を
>>          最大の目的とし、バグが報告されたという事実をもって満足する。BTS と
>>          しての完璧さは放棄する。

 どこかで割り切りが必要だという判断はわかりますが、割り切るポイントは
ここじゃない(これくらいは、小さな負荷で実現できるんだから、やるべきで
ある)と考えます。

>> …と書いてみましたが、考えれば考えるほど実際にメインテナの仕事をし、
>> BTS のメールを受けとった経験がなくては意義ある提案が行えない、と感じま
>> した。上記提案がボロクソに言われても全くしかたがないと思います。

＃えーと、長いので、書いてるうちに言葉がぶっきらぼうになってる
＃ような気が自分でしてきましたが、ボロクソに言ってるわけ
＃じゃないので ^^;; ねんのため。

 それはわかるのですが、ただ、佐野さんが -users に話題をふったのは、
BTS を利用する人の立場に立った場合、これってどう思う? 有効かな?
もしこんなこと始めたら、みんな使う? とか っていうような意見を
求めるためなのではないかな って気がします。

＃でしょ? > 佐野さん。

 なので、思いついたことを言ってもらえればいいし、多少 的はずれなら
つっこみが入るだけですし ;-)

 ところで、古澤さん もし JP BTS で上記の提案のようなことを
始めた場合、あなたは利用されますか?

＃下の話にもつながってくるんですが。

>> ただ、憶測ですが、現在 BUG 報告の過程で
>>
>>   ・原因まで自分でつきとめてしまえる人の場合 -> 本家に直接投げる

 これは、本来 推奨されるべき行為ですね。自分で報告できるなら、
自分で報告するのがいいと思います。

>>   ・原因特定には至らない人 -> メーリングリスト -> 識者 -> 本家へ

>> という流れは存在しませんか？ 原状の方法でも負荷分散並びに言語障壁の
>> 緩和という機能はある程度実現されていて、敢えていうなれば
>> 後者の場合に誰が BTS を行うのかで揉めることがあるという程度にも思えます。

 えーと、このパスは確かに存在するとは思いますが、別のパス(JP BTS ->
Official BTS)を増やすことで、さらに敷居を下げられる & クオリティを高め
る方法を増やすことになる(かもしれない)とは思いませんか?

>> この場合には誰にバグ報告をする責任があるのについてあらかじめの
>> 合意があればそれで足りるのではないでしょうか(はじめての人には手助けが
>> 必要かもしれません)。

 そうかもしれませんし、そうではないかもしれません。

>>   もちろん提案を実現することは素晴しいことだと思うので、実現される
>> ことを望みますし、また自分自身隙があれば協力できるように頑張りたいと
>> 思います。以上ご参考までに。

 という感じですが、どうでっしゃろ? ^^;;

-- 
いしかわ むつみ
 <ishikawa@xxxxxxxxxxx>, <ishikawa@debian.org>, <ishikawa@xxxxxxxxxx>