[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:26595] Re: 御意見募集 : JP BTS について
古澤です。
間が空いてしまいましたが、
> Debian JP の佐野です。
>
> 先日から jp-policy ML で Debian JP Project の BTS について、
> 運営方針を変更すべきかどうかという議論が行なわれています。
>
> (<http://lists.debian.or.jp/jp-policy/200101/> 参照)
<中略>
>
>
> で、実際にやるかどうかはまだ (すくなくとも、正式には) 決定してない
> と思うのですが、利用者としての需要がどれくらいあるのか、とか
> こういった作業 (*) に協力してもいいかな、という人はいるのかな、とか
> そのあたりをちょっと聞いてみたいなと思ってこっちの users ML にも
> 流してみます。
<中略>
>
> (*) 具体的な作業としては
>
> | JP maintainer は package を build/upload はしない(*1)かわりに
> | package の maintainance における日本語でのユーザ対応の部分を
> | 担当することになります。つまり
> |
> | - 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 の気持ちで 対応するという感じでしょうか。
> |
> | ユーザ <-- 日本語 --> JP maintainer <-- 英語 --> maintainer/upstream
> | BTS/JP BTSなど
>
> といった感じで、まずは報告されたバグレポートについて報告して
> くれた人に現象を詳しく聞いたり、実際にパッケージを使ってみて
> 確認するといった「バグの同定作業」や、特に同じ内容の報告が
> たくさん届いたりした時にひとつにまとめる (マージ) する作業などが
> 必要になると思います。
>
> ということで、御意見などあればお願いします。では。
>
上記の提案は bug fix の負荷分散(単位は国?)と、 日本語圏内における
bug 報告の促進が目的ということですよね。
この目的に反対する理由は全くないのですが、意見をもとめられても users
な人間(devel に参加していない)の立場からすると反応しにくいと思います。
というのは実際にメインテナとして作業を体験していない私のようなusers
の人間にとって(ひとくくりにするのもなんですが)、提案のような全体の負荷
総量より平均負荷をさげるようなシステムの変更に伴う、中間に立つ JP のメ
インテナの方々の負担がどの程度増えるのか、またその効果を判断しかねるか
らです。
JP メインテナの方々の中からこのような案がでてくるからにはきっと具体的な
解決策が前提にあると思うのですが、たとえば以下のようなことが気になりました。
・ Debian パッケージは数千あって、中間メインテナはその全てに対応する
可能性があるがそれは果たして可能なのか、そしてその役割の分担方法は？
・バグトラッキングシステムの途中経過、クローズ報告を本家と連動させるのか？
阿呆なことを書いてしまったかもしれませんが、それは devel で活動していない
人間の書くことですので失礼はご容赦ください。
さてこれは後者の問題について提案です：
================================================================
JPパッケージでないバグ報告については、本家とJPでフル装備の BTS を二
重に走らせるのは大変なので、中間BTS(JP) には中間メインテナの行った
作業のみを書く。
バグがJPに報告される-> JP メインテナの判断や行動(棄却しました or
patch を作成し
本メインテナに
投げました、など)
本家でのクローズやその過程を追い反映するのは負担大なので一切行わない、
必須な記録はバグが報告されたことと、中間メインテナが起こしたアクションのみ。
その他の状態(バグがクローズされたのかどうかなど)は本家 BTS に任せる。
主旨： 「言語の璧が問題となってバグ報告が渋られるような事態を防止すること」を
最大の目的とし、バグが報告されたという事実をもって満足する。BTS と
しての完璧さは放棄する。
================================================================
…と書いてみましたが、考えれば考えるほど実際にメインテナの仕事をし、
BTS のメールを受けとった経験がなくては意義ある提案が行えない、と感じま
した。上記提案がボロクソに言われても全くしかたがないと思います。
ただ、憶測ですが、現在 BUG 報告の過程で
・原因まで自分でつきとめてしまえる人の場合 -> 本家に直接投げる
・原因特定には至らない人 -> メーリングリスト -> 識者 -> 本家へ
という流れは存在しませんか？ 原状の方法でも負荷分散並びに言語障壁の
緩和という機能はある程度実現されていて、敢えていうなれば
後者の場合に誰が BTS を行うのかで揉めることがあるという程度にも思えます。
この場合には誰にバグ報告をする責任があるのについてあらかじめの
合意があればそれで足りるのではないでしょうか(はじめての人には手助けが
必要かもしれません)。
もちろん提案を実現することは素晴しいことだと思うので、実現される
ことを望みますし、また自分自身隙があれば協力できるように頑張りたいと
思います。以上ご参考までに。
ではでは。
_/_/_/ -@-----------------------------------------------------@-
_/ |Furusawa Hirofumi: fsawa@xxxxxxxxxxxxxxx Chiba, Japan |
_/_/_/ +-----------------------------------------------------------+
_/ | Organization: Chiba Univ. Department of Law and Economics |