From: Katsuya Kobayashi <[email protected]> Subject: Re: [ja-dev] OpenOffice.orgコミュニティの開発提案情報の読み方 Date: Fri, 18 Sep 2009 13:52:22 +0900
> koheiさん、小林です。いつもアドバイスありがとうございます。 > > ・日本の要件もリソースを投入すれば採用されうるなど従来より改善 hduとkaiと話せば、CJKに対してリソースが足りなくて難しいということが すぐわかります。また、issueをみると担当者が削られてきているのも分かります。 他力本願ももうまわらないでしょうね。 つまり、こちらから改善要求だしても、それはIssueになってパッチを投げても、 そこで終わりです。自分たちで回すことが重要です。 自分の言語は自分で処理、それは当たり前のことです。 昨年の北京では、arabicに力を入れるとWriterのleadなどが言ってました。 相対的にはCJK投入のリソースは減るでしょう。 > ・厳密には事前提案とUX仕様提示から始まるが現実は柔軟対応可能 > ・HamburugチームにはきちんとIssueで通知して作業を進めること 私の経験でもFBSD portingでも幾つかcwsつくってqaして、integrateしました。 結構素直でしたよ。大変でしたが。いまはbuildbotがありますし、比較的 楽にはなってきたように思えます。 > という基本を踏まえて、一度、開発フローを自分なりに整理してアプローチ > していこうと思います。 > > 日本語もしくは日本で優先度の高い項目を、４つくらい考えています。 > テーマごとにアプローチが異なるはずなので、またテーマが具体化したら、 > 伺います。 > > では、また。 > > 2009年9月18日12:51 Kohei Yoshida <[email protected]>: >> On Thu, 2009-09-17 at 21:18 +0900, Katsuya Kobayashi wrote: >>> （まだない日本語プロジェクト開発サブプロジェクトに関心のある皆様） >>> >>> 小林＠日本語プロジェクト・マーケティングメンバです。こんばんは。 >>> ＃[email protected]と[email protected]に最初はクロスポストお許しください。 >> >> [email protected]のみに返信します。 >> >>> これから、日本でも多くのOpenOffice.orgの導入が進むと予想していますし、期待しています。 >>> マーケットのパワーがまだ小さい段階で、日本語ないし日本の機能改善はなかなか優先度が >>> あがらないのが実情ではないでしょうか。 >> >> 優先度については、現段階では手を挙げて実際に開発してくれる人材がいる場合 >> はそれに合わせてある程度優先度を挙げてくれます。 >> >> 以前はそうではなかったんですけどね。開発する人間がいて、パッチを書いても >> それがSunの開発プランに沿ってなければなかなかパッチを取り入れてもらえま >> せんでした。かなりつじづまが合わずひどい状態出した。でもここ最近ではその >> ような難関はかなり取り除けられ、誰かがコードを書いて、本流に取り入れて欲 >> しいと頼めば(まだ例外はありますが)取り入れられる環境が出来つつあります。 >> >> そうは言ってもまだまだ難関が全く無いわけではないですけどね。 >> >>> ハンブルグの仲間たちや中国の仲間たちともどう力を合わせていけばよいのか考える意味でも >>> まずは、OpenOffice.orgコミュニティの開発プロセスがどのように仕様決定から開発・試験に進む >>> のかを、理解したいと考えました。 >>> >>> 全体のフローはどこかにありますでしょうか。ご存知の方があれば、教えてください。 >> >> Sunの提起するフローは存在しますがそのフローに沿わなければ絶対にだめ、と >> いう訳では無いのである程度は融通が聞きます。ようはコードがあるか無いかに >> よるわけで。 >> >> 全体的に言うと、こんな感じになってます。 >> >> コードを書いて、新機能を開発する。この時、Sunとしてはコードを書く前にSun >> 開発陣に一言言って、UXにもメール投げて議論を促す、くらいはして欲しいよう >> なんですが、現実問題そんなこと出来る余裕が無い場合が多いので、余りここら >> 辺は曖昧でいいようです。僕の場合は、企業で働く立場上コード書く前にそれを >> いちいち公式発表してはいられないので、このステップは大抵の場合はパスして >> ます。 >> >> Issue Trackerで機能要望が無いかどうか検索し、あればそこで「自分がこれを >> 今開発中である」という事を述べる。ただこの場合も、簡単な機能の場合は先に >> パッチが出来上がってからそれをattachしてその時に「こんなの書いてみた >> よー」という感じで行ってもOK。でも複雑な機能で、コード変更も大幅にしなく >> てはならない場合はパッチではやや面倒です。その場合には、CWSを作成し、そ >> の際にその機能に相当するIssue Numberを登録し、そのIssue内でもその旨連絡 >> してからそのCWS内で開発をし始める、という手順が必要になります。その時に >> はそのCWSで開発されている機能に相当するIssueを自分にassignし、statusを >> startedにすることにより、他の開発陣に「自分が今この機能を実際に開発して >> いる」という事を知らせることが出来ます。 >> >> で、その機能の開発が終わった時点でそのCWSのstatusをready for QAとし、QA >> 代表の人にじっくりQAをしてもらいます。で、そのQAがパスした場合はQA代表の >> 手によってstatusがapproved by QAとなり、そのCWSはリリース・エンジニ >> ア(RE)の手に渡ります。で、REがそのCWSをintegrate出来ると判断した場合(こ >> の辺は僕も曖昧です)、CWSのstatusがnominatedに変わり、REの手によってCWSが >> masterへとintegrateされ、smoke testが通れば晴れてintegratedとなる訳で >> す。このようにして一度integrateされれば、次のマイルストーンでその機能が >> 試せる、という訳ですね。 >> >> ただここで一つ注意すべき点は、もしその機能がなにかしらのデータをファイル >> に保存しなければならない場合、ODFのフォーマット変更を余儀なくされます。 >> この際にはODF TCという別団体にその変更を提案し、それがacceptされないとそ >> の機能自体がOOoに取り入れられる可能性がガクンと下がります。 >> >> その他にも、UIの変更を必要とする機能の場合は仕様書を書く必要があります。 >> この仕様書は主にQA代表のために書かれるものであって、QAをする際にその機能 >> が期待どおりにちゃんと機能しているかどうかを確かめるために書くものです。 >> 人によっては仕様書を先に書く人もいますが(Sun内部ではこれが必須？)、僕は >> いつも機能が出来上がってから書いています。 >> >> まぁこんな感じでしょうか。新機能ではなくバグフィックスやビルド関連のCWS >> の場合は仕様書やODF変更は勿論必要無いので、そこら辺は省略出来ます。 >> >> ではでは。 >> >> Kohei >> >> -- >> Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. >> <[email protected]> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > >
pgpSDiyNUkjZW.pgp
Description: PGP signature
