[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:26602] Re: 御意見募集 : JP BTS について
古澤です。
# 長文注意!
ishikawa@xxxxxxxxxxx さんは書きました：
> むつみです。
>
<中略>
> さきほども言いましたが、これはたぶんに実験的要素も含んだ試みなので、
> 問題があるようなら、修正 or 廃棄(やめやめ、あかんわ これじゃ)という
> 判断になることも十分考えられるでしょう。
>
> >> JP メインテナの方々の中からこのような案がでてくるからにはきっと具体的な
> >> 解決策が前提にあると思うのですが、たとえば以下のようなことが気になりました。
>
> えーと、いま書きましたが 実際にやってみないと問題点が見えないだろうと
> いうのがあるし、やりながら修正でも ええやんという 感じだったりします。
> (すくなくとも、おれの中では)
>
<中略>
> で役割分担ですが、前述の URL から、スレッドの最初の方を読んでもらえれ
> ばいくつか案が出てるますが、具体的に決めた段階ではありません。
>
> 1) Debian JP かつ Debian Official なメンバーな場合は、その人
> 2) それ以外 のパッケージは各自のチョイスで得意/必要な物を
> たとえば、jtex とかメンテナンスしてれば、必然的に tetex パッケージ
> とか、そっちも見ないといかんだろうから、関係するパッケージとかも
> 担当してくれるとうれしい
> 3) でもって、あとは やりたいもの
> 4) QA チーム(的)を編成しておき、担当がないものに対してのリポートは
> そのメンバーが担当
> 5) その他、単発で「このバグレポートは私が処理するっす」というのもアリ。
>
> とかでしょうか?
>
users 的には突っこむべきではないかもしれませんが、
BTS はパッケージ名からメインテナを割出してメールを転送する仕組みな訳
ですよね？ 4) は JP メインテナ不在パッケージの場合 QA(って何？) チーム
全員にメールが転送されるというイメージなのでしょうか。
<中略>
>
> どちらかというと、テクニカルな作業より、バグ報告者との間、および、
> メンテナとの間のインタラクションの方が多くなるものと思われます。
>
> >> さてこれは後者の問題について提案です：
> >> ================================================================
>
> >> 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 で上記の提案のようなことを
> 始めた場合、あなたは利用されますか?
>
問われてみるまでは「利用しない、本家に投げるようにする」つもりでした
が(keep it simple)、今は迷いが生じています。というのは「負荷分散」の効
果に着目するかどうかが難しいからです。
自分が未解決のバグを発見した場合を例にとりますと、今までは
・自分で原因を特定できた場合
どこを修正すればよいのかを本家メインテナの方に報告。このと
きに生じるコストは、自分とバグを修正する本家メインテナの方に発生
・自分で原因を特定できない場合
ほとんどのコストが本家メインテナの方に直接発生。
していたわけですが、「自分で原因を特定できない」場合に新 JP BTS を利用
すればJP メインテナの手により本家メインテナの方への負荷が分散される可
能性があるということになりますよね。そして一方で問題解決全体に要するコ
ストは増大すると考えていいと思います。
さてどちらを使うのがみんなの幸せになるのでしょうか？
難しいところですが、現時点での自分の考えとしてはもし原因が完全に特定で
きた場合には直接レポート、見当だけのときは JP BTS、まったく疑問だらけ
の場合はメーリングリスト行きという感じになると思います。間に人を狭んだ
方がいろいろな技術力の人が参加できる可能性が高くなる、マンパワーを集め
やすいのではないかと感じるからです(ただし逆に集まらないと達人のパワー
が削がれてしまうのではないかと危惧)。性格がらいろいろといらぬ心配して
しまってご迷惑をおかけしております、結局実行あるのみなのでしょうね。
と、こんな感じで「自分だったら JP BTS と本家 BTS はこう使いわける」
という意見が出ると devel な方々の参考になるんじゃないでしょうか。
もどって佐野さんの期待なされた「意見」というのはたとえば
「私本家 BTS は恐くてバグを発見したにもかかわらず默っていたことがあり
ます。」
という具体的な体験や
「んなもん作っても誰も使わないだろ」
などの user 的なものであったと思いますがあまり反応がないようですね。
おまけとして自分自身の体験を書きますと、はじめての BTS はたしかに恐怖
というか非常に面倒でした。そしてその理由には明らかに英文メールが
ありましたね。数年前の users に今はバリバリのメインテナの方が
BTS に英文メール投げるのを不安そうに書いていたこともありますし
日本語バグ報告のニーズは確実に存在すると思います。
# ただ JP BTS があるがために開発者と直接コンタクトをとる人が
# 減少することがあるとしたら、それは少し残念だと思っています。
> ＃下の話にもつながってくるんですが。
>
> >> ただ、憶測ですが、現在 BUG 報告の過程で
> >>
> >> ・原因まで自分でつきとめてしまえる人の場合 -> 本家に直接投げる
>
> これは、本来 推奨されるべき行為ですね。自分で報告できるなら、
> 自分で報告するのがいいと思います。
>
> >> ・原因特定には至らない人 -> メーリングリスト -> 識者 -> 本家へ
>
> >> という流れは存在しませんか？ 原状の方法でも負荷分散並びに言語障壁の
> >> 緩和という機能はある程度実現されていて、敢えていうなれば
> >> 後者の場合に誰が BTS を行うのかで揉めることがあるという程度にも思えます。
>
> えーと、このパスは確かに存在するとは思いますが、別のパス(JP BTS ->
> Official BTS)を増やすことで、さらに敷居を下げられる & クオリティを高め
> る方法を増やすことになる(かもしれない)とは思いませんか?
>
もちろんよい効果があると思いました、しかしそのためのコストは大きいの
ではないかと思ったのが前投稿の「躊躇」の主要因でした。
むつみさんの丁寧な BTS 技術解説のおかげでシステム的なコストはそれほ
どでもないということが分ったので今は殊に引っかかる要素はなくなりました。
<中略>
> >> もちろん提案を実現することは素晴しいことだと思うので、実現される
> >> ことを望みますし、また自分自身隙があれば協力できるように頑張りたいと
> >> 思います。以上ご参考までに。
>
> という感じですが、どうでっしゃろ? ^^;;
納得いたしました :-)
_/_/_/ -@-----------------------------------------------------@-
_/ |Furusawa Hirofumi: fsawa@xxxxxxxxxxxxxxx Chiba, Japan |
_/_/_/ +-----------------------------------------------------------+
_/ | Organization: Chiba Univ. Department of Law and Economics |