中田さん、 詳細な解説ありがとうございます。
NAKATA Maho wrote: > Toraさんにお薦めするのは、このOOE680_mXなどの > 日本語版Windowsをフルビルドして確認する、です。 なるべく早い時期に改修内容を確認する。というのは共通認識だと思います。 早くするために発生する人的リソースのコストをどうするのか、というのは、 議論の余地があるのではないでしょうか。 Hamburg において、コードを書く人、ビルドする人、テストする人とそれぞれ 役割分担がなされているわけですが、それと同じ仕事量を日本において一人の 人がバグを報告し、コードを書く人とやりとりし、ビルドし、テストする、 としてしまっては、数回は出来るでしょうけど、長く続く方法だとは思えません。 もしやるのであれば、日本においても、Hamburg 同様、中身はわからないけど ビルドは得意だぜぃ担当、ビルドは面倒だけどテストなら任せてくれ担当、 技術はよくわからんけどどのバグがどうなっているか追跡・管理するなら俺に まかせてくれ担当、作り方なんかわかんねぇけど使うんだったら俺が一番だぜ 担当、、、などというように役割・作業分担するというのも、１つのアイデア かと思います。 > [EMAIL PROTECTED]@ja.oo.oでリリース直前に問題定期つけても直らない」 > という状況は回避できます。 2.0.3 開発当時に行なわれた不具合の修正方法が期待通りでなかった。その修 正内容を確認していなかった。というのが今回の議論の発端だと思いますが、 それは、確率的に言って、数十から数百個のバグ改修の中の１つだと考えてい ます。すべてのバグ改修内容について、すべて日本側にてビルドしテストする というのは、コストが掛かりすぎるのではないでしょうか。 コストと影響の大きさとのバランスを考えてみてもよいのかと思います。 コスト削減、しかし品質は維持しよう、という方向から考えると、他の人がやっ ていることはなるべく重複しないで、というか人の仕事を取らないで、相互に 補完しあいましょう。というアイデアも１つの方法かと思います。 2.1 リリースに向けては、開発版や TCM テスト用の版や、リリース候補の版や と何度もフルビルド作業が Hamburg の人たちによって行なわれています。 適切な版、時期にタイミングよくバグ改修が期待通り行なわれたか確認テスト するというのが、重複作業を避けてコストを掛けずに、かつ、品質は維持する、 という解決案の１つになるのかと考えています。 現状の日本のコミュニティで取り組んだらいい点は、開発の全体の流れをつか み、どのバグがどのような状態になっているか追跡・管理し、タイミングよく、 必要な作業をコミュニティの人たちへ指示する人かと。 Tora --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
