小笠原です。
いくやさんのメールを読んで、 >> 2. 開発中のプロジェクト（例：5.0）に対しては、RC3までは同じ >> 変更を手で反映する（提案者は両方に提案を行い、査読者は両 >> 方を査読する） これはまったくの悪手だなということに今更ながら気づきました。 どうやるかの方法論はさておいて、 > branchで翻訳した後masterに反映させる 方が、時間的余裕はあきらかにあるので、その方針を採りたいと思います。 プロセスとしては： 1. リリースの谷間（前のバージョンの .0リリース〜新バージョンのβ） に関しては、変更は必ず master に反映する。 1-1. リリースされたものに適用したほうがよい変更、すなわち明らか な誤りなどについては、masterおよび任意のブランチに提案を行い、 MLでその旨知らせる。 変更内容については変更が適用された時点でwikiに記載する。 （これは原則、今までの変更ルールと同じ） 2. 新バージョンのβリリース〜.0リリースについては、変更は最新の ブランチに反映する。 3. .0リリースが出た後、翻訳コーディネータはブランチの変更を masterに反映する。（方法はTBD） という感じで如何でしょう。＞みなさん L10N MLでの議論によれば、masterの存在を完全に無視して、 ブランチだけで作業すれば今までと同じプロセスになるので、 各国語翻訳プロジェクトとしてはそういう選択もありうる、とのこと でしたが： ・9週間という短納期に縛られず翻訳ができる ・翻訳の仮定でnightlyなどを用いて新機能を見る機会が増えるので、 先行して機能把握がしやすくなる というメリットもまた捨てがたいところがあるので、個人的にはmaster プロジェクトを活用する方法を考えたいところではあります。 # が、そこのところも、もちろん議論の余地はあります。 > branch作成前に翻訳するというのも手ではあるのですが、新機能が出揃ってな > いので結局のところ中途半端になります。 > そう考えると、branchの作成タイミングをBetaリリース時じゃなくてRCリリー > ス時にする、というのが落としどころとして悪くない気がしてきました。 なるほど、それは一つのアイディアですね。 あまり英語は得意でないので、MLなどでタフな交渉をするのは正直、 私としてはしんどいです。が。 お約束できるわけではないですが、今年のLibO Confにて、NLP BoFを コミュニティデーでやるよという案内をもらっています。 その席で交渉を試みるのは可能かもしれません。面と向かってるほうが、 まだやりやすいので。 では。 -- Naruhiko Ogasawara ([email protected]) -- Unsubscribe instructions: E-mail to [email protected] Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/ja/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
