Maho NAKATA wrote: > ドイツ語、フランス語、イタリア語のコミュニティのQAは強い。これだけでは無く他言語も > 結構強い。これからは中国語も強くなります。なんとPeter Jungeも引き抜かれました。 > 我々はそのまま、4年、彼らにおくれています。IssueTrackerにもほとんど日本人らしきひとは > 見当たりません。リリース候補でバグを発見し、リリースをストップさせるほどの強力な > 力を持つのは夢のまた夢かもしれません。ですが、それには近づきたい。
ここだけ、反応しますね。 『リリースをストップさせるというほどの強力な力を持つのは「夢」』なんていう 考えは、今、即刻、止めて下さい。 ましてや、ヒーロー気分に浸って世界の人達に注目される必要なんてないんです。 あなたは、QA プロジェクトのleadにも自ら立候補して今その立場にいるのでしょ。 そんなこともわかっていないからだと思います。QAプロジェクトの人達から相手に されていないでしょ。2.2.1 リリースの判断の会議にもQAプロジェクトの現リード である中田さんの名前は無かったし。 まあ、これ以上悪口を言うのは止めなくちゃいけない。そろそろこちらから謝らな ければ。と考えているとこななんですけど。それはさておき、 リリース作業をストップさせるデメリット 1. コミュニティがやる気を無くす 2. 開発が遅れる負のスパイラルへ陥る 3. リリースを待っているユーザーの計画が立たなくなる リリース候補が次々に出てくると、各言語のコミュニティの人達は、どうのように 感じます？ 日本語の場合は、RC1はテストせず、2もテストせず、、、どうせまた 次のリリース候補が出てくるんじゃないの？ と。英語版がリリースされた後、 あわてて、何日も掛かるような重たいテストをやりだす。 (フランス語やドイツ語のコミュニティでは、RC1 から着実にリリースに向けて何を テストするべきかという目的に沿ったテスト作業を積み重ねてきているのではない でしょうか。そして、英語版リリースとほぼ同時期に自言語版をリリースできる。) リリースをストップさせていると嫌疑を掛けられたモジュールの開発者は、本来やる べきことを犠牲にして、そのバグの対応に追われる。他の開発者達はすでに次の版の 開発に取り掛かっている。そのモジュールの次の版で予定されていた開発計画は遅れる。 しかも、コミュニティ側からしてみると、次の版の開発版のビルドが出来上がってきて いて、本来であれば、リリースのQAなどとっくに終わっていて、その開発版のテストを コミュニティは行なうべきであるにもかかわらず、それには手を回せず、まだ完了して いないリリースのテストに時間と人を取られる。結果、次の版についての、開発側の開発 の進みとコミュニティ側の開発版のテストとが、どんどん離れていく。 今日現在においても、次の版の開発版のビルドがアップロードされてきているでしょ。 コミュニティは、本来であれば、今、その開発版に取り組んでいるはずなんです。 OpenOffice.org はユーザーに使ってもらってなんぼでしょ。大口のユーザーやシステム は○月○日カットオーバー(テープカットなどのシステム稼動開始の日)予定などで、 計画して進んでいきます。リリースの予定が定まらないどころか、そのような「夢」のため にどんどん遅れてくというようなリリースのされ方では、ユーザーは困ってしまいます。 2.2.1 は 2.2 のバグ改修版とのこと。どうせなら、2.2 ではなく 2.2.1 をシステムに インストールしてカットオーバーを迎えたい。しかし、公式にリリースされていないの ならば、2.2 で我慢する。一旦インストールしたシステムは一年から数年間は別の予算が つくまでいじれない。そんな望んでいない状況を回避するためにも、コミュニティが安定 してスケジュール通りにリリースするというのは、非常に重要なことではないでしょうか。 リリース候補でバグを見つけて、ヒーロー気分でリリーススケジュールをぶち壊すのではなく、 リリース候補よりも数週間前の時期に出てきている開発版で重大なバグを見つけて、世界の コミュニティメンバーからの賞賛をもらうようしよう。と考えを改めてください。 では Tora > よいリリースをなるべく早く、限られたリソースで。これが目標です。 > > 少し歴史的なことを述べましょう。 > > OOoはボランティアによって構成されています。特にHamburgチームというSUNのボランティアが > 翻訳もいくつかのローカライゼーション(日本語含む)も > 主に面倒を見ています。これは超強力な開発者の集団で、成果をStarOfficeとして販売しています。 > まさに、彼らの利害はそこにあり、OOoは本当のヴォランタリーワークです。だから > ソースコードも含めて、OOoには直接関与しません(実際は人間関係がだぶっていたり、政治的 > 理由で関与していますが)。 > > OOoは懐が広く、全ての言語、全てのプラットフォームを受け入れます。これは素晴らしいことで、 > わたしもFreeBSD/MacOSXには無視できない時間関わり、そしてパッチは100単位で > コミットされました。わたし自身もコミットしています。 > > [メールアドレス保護] > MLには、「このような言語のビルド、プラットフォームの > ビルドがある」というメールが投稿されますが、 > あるftpサイトににある、ビルドをどのようにオーサライズしてよいか、というのは不明でした。 > もしかしたらウィルスが入っているかもしれない。そこに統制が必要でした。 > > そこで、2003年にOOoではリリースする際に、QAをしなくてはならない、としました。 > これはコミュニティマネージャーのLouis Suarez-Pottsの提案です。 > すぐさまQAプロジェクトのJoost, Gordon Sらによって承認されました。 > > だから、1.0.2までは`RC'(リリース候補)という表記がなかったのですが、 > 1.0.3からは全てのビルドはリリース候補であり、QAをしなくてはリリースされなくなりました。 > QAの責任は各native language projectのproject leadがとるということです。 > これは自然な流れだと思います。l10nもdevもqa projectもこれは担当するのは > あまり好ましくない(l10nはlocalizationで開発、qaはquality assuranceは > しますが、各言語については知らないから)。 > > わたしは当時JA-NLのプロジェクトリードでありましたが、最初このQAの重要性を全く > 認識していませんでした。全くとんちんかんな見解を持っていました。 > そのような状態でQAをコンダクト出来るはずもなく、 > 手をあげられた近藤さんに一任していました。わたしは何も手伝わなかったですが、全く彼の好きなように > やってもらっていました。彼は長いことQAをしていましたが、力尽きました。3-4年前彼とLouisと三人で > ご飯を食べたときがあります。その時「中田さん、ごめんなさい」とすまなそうに > していて、とてもこちらも辛くなりました。 > > その後は、武内さんがQAを継ぎました。彼にも平野さんと三人で数年前OSCのときに一度あいました。 > よいQA管理者だったと思います。vmwareがあれば、もっと速いコンピュータがあれば、 > とおっしゃっていました。JREもwithout JREもファイルが完全に同一かどうかチェック > すべきだとおっしゃっていました。なかなかマニアックな人だなと思いました。 > ですが彼も力尽きました。個人的なことを色々聞くと、大変な激務を担ってくれた > 武内さんには本当に感謝しています。何か寄付できたかも、それを思うと > 心が痛くなります。 > 武内さんはwikiを使っていたようです。アクセス過多か、突然、パスワードが必要となりました。 > > そして、彼らのQAの詳しい記録はほとんど残っていません。 > > QA担当者はかなりの激務です。大抵はQA担当者が多くQAしていたと思います。 > そして二〜三週間はかかりっきりになります。 > 皆はOOoをすぐさま使いたい、そう思うと思います。それは自然です。 > でも、このようにQA担当者を酷使し、一人一人潰していくのは、プロジェクトとしては > 辛いもので、これからは絶対にそのようにすべきではないと考えます。 > そして記録もあまり残っていません。こんな、焼き畑農法のような、QAは徒にテスターを疲弊させます。 > 全く成果があがらないし、OOoにフィードバックも不可能です。これならば、QAの要件を > 「ビルドが入手されたらそれでリリース許可」にするほうがよほどよくみえます。 > しかし、これは、全くQAを放棄すること意味し、OOoの信頼性は低くなるので > これもできません。 > > つづく... > -- Nakata Maho > ([メールアドレス保護]) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [メールアドレス保護] > For additional commands, e-mail: > [メールアドレス保護] > --------------------------------------------------------------------- To unsubscribe, e-mail: [メールアドレス保護] For additional commands, e-mail: [メールアドレス保護]
