コミッター作業担当について

[tai]

Miyoshiさん、

> trunk
> の継続性がそれほど重要ではないのではないかと思ったんですが、どうなんでしょう。

なーる！！そうですね。
では「メジャーリリースごとのローテーション」ではなく「ブランチごとのローテーション」にしましょうか。

作業担当一覧に追記しました：
http://groups.google.com/group/wp-ja-pkg/web/%E4%BD%9C%E6%A5%AD%E6%8B%85%E5%BD%93%E4%B8%80%E8%A6%A7

--
たい

[tai]

Makoさん、

> > 1. メジャーリリースごとのローテーション
> > * メジャーリリースごとにリーダー（まとめ役）と担当を決める
>
> これも動き始めてみないと実感がわかないので、まずはこれでいいかと思います。
> もし私がリーダーになる回のことを想像してみると、2,3日続けてネットから離れることがしばしばあるので、そのときに対処しなければならないことが起
> こることを考えると、サブをどなたかに決めてそのことをお願いしたいと思います。
>

各ブランチ（メジャーリリース）のサブリーダーも決めましょう。:-)

tenpuraさん、

> ・最新安定版は、/trunk
> ・2.0系は、/branches/2.0
>
> でメンテするというのはどうでしょうか？
> 安定版しか取り扱わないというのであれば、この2本で足りる気がします。

作業担当一覧
http://groups.google.com/group/wp-ja-pkg/web/%E4%BD%9C%E6%A5%AD%E6%8B%85%E5%BD%93%E4%B8%80%E8%A6%A7
の「作業サイクル」に書いたように、現行版と次期版のサイクルが重なる場合があるので「メジャーリリースごとのローテーション」ではなく「ブランチごとの担当」ではどうでしょう？

2.0系は日本語リソースの変更はほとんどないと思うので別の担当と兼ねてもいいかもしれません。

> ローテーションに関しては現在までの翻訳作業の流れがわからない
> からなんとも言えませんね。
> スケジュール管理や具体的な作業分担はどのように行われてきましたか？

今までの翻訳作業の流れは、私が更新分を翻訳してMLで皆さんに校正を依頼し、
その校正を取り込んで私がコミットする、という感じです。また直翻訳が必要なファイルも
私がTracでバージョンを比較してその都度アップデートしてました。

スケジュール管理は、実作業者が私一人だったこともあり、特に何もしていませんでした。

作業分担は、直翻訳が必要なファイルの最初の翻訳はみんなで分担し、その後の更新は他のすべてを含め、私がしてました。

つまり、作業分担、スケジュール管理など今回が初めて:-)というわけですので、大枠で合意できればあとはおいおい詰めていけばいいかと思いますが、いかがでしょう？

[tenpura]

taiさん

> 現行版と次期版のサイクルが重なる場合があるので「メジャーリリースごとのローテーション」ではなく
> 「ブランチごとの担当」ではどうでしょう？

次期版のソースを追いかけるというのであればやはり trunk も使って
きっちりと本体リポジトリの管理形式に合わせるのが最善だと思います。つまり

・次期版の管理は、trunk で
・ja の 各branch の生成は本体側で該当tag（あるいは branch）が作られたタイミング以降に
trunk から対応する完成リビジョンをコピーして開始

といった形です。整合性保持の理由からこのようにした方が良いと思うのですがいかがでしょうか。

> 現行ブランチから次期ブランチを作成
> （例：2.3 ブランチから 2.4 ブランチを作成 - svn copy 2.3 2.4）

というようなことをやると2.4系ではないソースがそのブランチに混入してしまいます。

本体リポジトリのソースを追いかける時にも構造やマナーが同じであれば
扱いや場所を探すのに迷うことも少なかろうと思います。

以下質問です。

Q.1

> 今までの翻訳作業の流れは、私が更新分を翻訳してMLで皆さんに校正を依頼し、
> その校正を取り込んで私がコミットする、という感じです。また直翻訳が必要なファイルも
> 私がTracでバージョンを比較してその都度アップデートしてました。

これをリリースリーダーが行うということでしょうか？

Q.2
安定版以外のパッケージも扱うのでしょうか？
もし安定版しか扱わないというのであれば、各安定版リリースの間近に
最新の該当ソースを取得して準備するというのが基本と考えてよろしいでしょうか？

Q.3
一度リリースしたパッケージに修正が必要な場合はどうしますか？
修正したもので同名で置き換えますか？

tenpura

On 10月17日, 午後6:27, tai <tek...@gmail.com> wrote:
> Makoさん、
>
> > > 1. メジャーリリースごとのローテーション
> > > * メジャーリリースごとにリーダー（まとめ役）と担当を決める
>
> > これも動き始めてみないと実感がわかないので、まずはこれでいいかと思います。
> > もし私がリーダーになる回のことを想像してみると、2,3日続けてネットから離れることがしばしばあるので、そのときに対処しなければならないことが起
> > こることを考えると、サブをどなたかに決めてそのことをお願いしたいと思います。
>
> 各ブランチ（メジャーリリース）のサブリーダーも決めましょう。:-)
>
> tenpuraさん、
>
> > ・最新安定版は、/trunk
> > ・2.0系は、/branches/2.0
>
> > でメンテするというのはどうでしょうか？
> > 安定版しか取り扱わないというのであれば、この2本で足りる気がします。
>

> 作業担当一覧http://groups.google.com/group/wp-ja-pkg/web/%E4%BD%9C%E6%A5%AD%E6%8B...

[tenpura]

追記です。
先ほどの trunk を使う案の例をブランチごとのローテーションに当てはめると

2.3 担当者の担当は
↓2.3 安定版のリリース（管理場所：trunk、回数：1回）、2.3 tag・branch の作成
（以後、trunk 管理は、2.4 担当者へ）
↓2.3.x 安定版のリリース（管理場所：2.3 branch、回数：数回）、2.3.x tag の作成

2.4 担当者の担当は
↓2.4 安定版のリリース（管理場所：trunk、回数：1回）、2.4 tag・branch の作成
（以後、trunk 管理は、2.5 担当者へ）
↓2.4.x 安定版のリリース（管理場所：2.4 branch、回数：数回）、2.4.x tag の作成

となります。

以上、安定版のみ扱う前提です。

tenpura

[tai]

> 2.4 担当者の担当は
> ↓2.4 安定版のリリース（管理場所：trunk、回数：1回）、2.4 tag・branch の作成
>  （以後、trunk 管理は、2.5 担当者へ）
> ↓2.4.x 安定版のリリース（管理場所：2.4 branch、回数：数回）、2.4.x tag の作成

基本的にbranchでのコード変更は機能の追加はなしでバグフィックスが主になるので、trunkにもほぼ同じ変更が入ると思います。
trunkも常に追いかけるとすると、現行branchの最終リリースまで二人が別の作業場所にほぼ同じ変更を加えることになります。
branchを引き継いでいくとすると、ベータ１までは作業の重複はありません。

例えば、2.3.1がもうすぐリリースされますが、jaでの更新作業は今のところメインのja.poに対する変更が2箇所だけです。
この変更はおそらくtrunkにも入っているので、trunk案だと2.4担当者はja/trunkに変更を適用する必要がありますが、branch案だとその必要はありません。

>> 現行ブランチから次期ブランチを作成
>> （例：2.3 ブランチから 2.4 ブランチを作成 - svn copy 2.3 2.4）
>
> というようなことをやると2.4系ではないソースがそのブランチ

> に混入してしまいます。

poファイルは本体コードもしくはpotファイルから生成/更新するので2.4系ではないソースが2.4ブランチに混入する可能性はありません。

po ファイル以外のファイルでは、確かにその可能性はあります、、が、これは翻訳側の作業としては、trunk更新（tenpuraさん案）でもbranch 更新（tai案）でもリビジョン間での差分を見て更新する必要があるので、更新を忘れたり間違えたりすれば結局同じことだと思います。

例えば、直翻訳が必要なaaa.phpファイルを2.4担当者が更新するとき、

• ja/trunkを更新して、そこからbranchを作成する場合（tenpuraさん案）：
1. Tracでaaa.phpの前回リビジョンと更新時リビジョンを比べ、更新されていたらその差分をja/trunk/aaa.php自体に直接適用する（このとき変更分の適用を忘れたら "2.3.0のコードが残る"ことになる）
2. もしくは、Tracかwp本体リポジトリからオリジナルのaaa.phpファイルを持ってきて、ja/trunk/aaa.phpを元に必要な箇所を翻訳する（この場合は本体コードは最新）
3. 以上を"2.3リリース以降 "、他のファイルも含め、更新するたびに行う
• ベータ１以降にja/2.3 branchからja/2.4 branchを作成する場合（tai案）：
1. Tracでaaa.phpの前回リビジョンと更新時リビジョンを比べ、更新されていたら差分をja/branch/aaa.php自体に直接適用する（このとき変更分の適用を忘れたら" 2.3.xのコードが残る"ことになる）
2. もしくは、Tracかwp本体リポジトリからオリジナルのaaa.phpファイルを持ってきて、ja/branch/aaa.phpを元に必要な箇所を翻訳する（この場合は本体コードは最新）
3. 以上を"2.4ベータ１以降"、他のファイルも含め、更新するたびに行う

tenpuraさん案で作業開始を2.4ベータ１以降としても、trunkでの2.3.0-2.4b1間の差分よりもbranchでの2.3.x-2.4b1間の差分の方が少ないと思います。

> Q.1

>> 今までの翻訳作業の流れは、私が更新分を翻訳してMLで皆さんに校正を依頼し、
>> その校正を取り込んで私がコミットする、という感じです。また直翻訳が必要なファイルも
>> 私がTracでバージョンを比較してその都度アップデートしてました。
>

> これをリリースリーダーが行うということでしょうか？

これを各担当が行なうということです。

• 各担当は自分の担当ファイルを更新し、更新報告や校正依頼をMLに流す。更新が無ければ無い旨をMLに流す
• リリースリーダーは自分の担当ファイル以外で上記の報告が無ければ報告を促すか、作業を代行する
• 各担当は校正を取り込んでコミットする
  

> Q.2
> 安定版以外のパッケージも扱うのでしょうか？
> もし安定版しか扱わないというのであれば、各安定版リリースの間

> 近に
> 最新の該当ソースを取得して準備するというのが基本と考えてよろしいでしょうか？
「安定版以外のパッケージ」とはベータ版やRC版ということだと思いますが、もしかしたら日本語（マルチバイト）特有のバグのある可能性もあるので、できればオリジナル版と同じようにリリースしたいと思います。

> Q.3
> 一度リリースしたパッケージに修正が必要な場合はどうしますか？
> 修正したもので同名で置き換えますか？
これは、、、どうしましょうか。
小さな修正なら同名で、大きなものなら別名ではどうでしょう？

[Mako]

理解が間違っているかもしれません。そのときは話をややこしくするだけなの
で、これは見なかったことにしてください。

要は、branch ができたあと、いつ trunk を作るか、その trunk の元はどこ
から引っ張ってくるか、という問題のように思います。

tenpuraさんのは原則的なもので、branch ができたら即座にtrunkを作って(残
して、というほうが正確かも)おく、ということでしょう。
　┌─┌─┌─
─┴┬┴┬┴┬─
　　└─└─└─
branchが生えるタイミングやtrunkの中身は本家に合わせるということで、構
造はわかりやすいと思います。

taiさんのは、branchができたあと、時間をおいてtrunkを考えればよい、次の
branchのタイミングまで待とう、ということはいっそ trunk を省略してしまって
　／　／　／
／＼／＼／＼
　　＼　＼　＼
の形でいいのではないか、ということでしょうか。

一見わかりにくいのですが、
いま作業の内容が「翻訳」ということを考えると、
(1)作業が少し出遅れても割とすぐに追いつける
(2)むしろ本家の作業が一定落ち着かないと手を付けにくい
(3)現行branchとtrunkの両方を監視するという手間を少し省ける
ということで、taiさん案が合理的なように思いました。

ただ、

>> 現行ブランチから次期ブランチを作成
>> （例：2.3 ブランチから 2.4 ブランチを作成 - svn copy 2.3 2.4）

ということだと確かに
> というようなことをやると2.4系ではないソースがそのブランチに混入してしまいます。
の危険性がありますから、branchから生える次のbranchの中身は

> 2. もしくは、Tracかwp本体リポジトリからオリジナルのaaa.phpファイルを持ってきて
> 、ja/branch/aaa.phpを元に必要な箇所を翻訳する（この場合は本体コードは最新）

とすればいいと思います。
古いコードの混入のおそれと翻訳忘れのおそれを比べたら、後者のほうがまし
だからです。

[tenpura]

Makoさん、taiさん

> の危険性がありますから、branchから生える次のbranchの中身は
> > 2. もしくは、Tracかwp本体リポジトリからオリジナルのaaa.phpファイルを持ってきて
> > 、ja/branch/aaa.phpを元に必要な箇所を翻訳する（この場合は本体コードは最新）
> とすればいいと思います。

これはそうなのですが、branchから次のbranchは生えません。
「あるブランチの終端と次ブランチの頭は繋がらない」のです。

この画像を見てください。
http://ethol.zool.kyoto-u.ac.jp/coe/image/hassei1.gif
右下にヒトまで伸びている線がtrunkです。上方向に分岐しているのがbranchです。
魚類を2.3 branch、両生類を2.4 branchと考えてみてください。
2.3系のお尻を2.4系の祖とするとフグが両生類の祖になってしまい
それぞれ独自進化を遂げる異なる枝の終端と頭が繋がらないことが分かると思います。
本当に2.4系の祖となるポイントは両生類ブランチの付け根の部分（2.4.0）であり
ここを作り出す為にtrunkを利用しようと言っているわけです。

①. あるブランチの終端と次ブランチの頭は繋がらない（上述）
②. ブランチの初回コミット内容は原則的に対応tagの内容と同じ（WP本体の管理）

という条件下で②の初回コミットの準備を行える唯一の場所がtrunkです。
ブランチのみの管理下にはこれがありませんので、どのようにしても無理が生じます。

また、いくつか手間を懸念される声があがっていますが
どれも取り越し苦労のような気がいたします。

> 要は、branch ができたあと、いつ trunk を作るか、その trunk の元はどこ
> から引っ張ってくるか、という問題のように思います。

/ja/branch/x.x は、/ja/trunk のしかるべきリビジョンをコピーして生成します。
/ja/trunk の更新は、本体 trunk と最新の日本語リソースを見比べて行います。
ブランチのみの管理で次期x.xを準備する段階に必要となる作業もこれと同じです。

> 3. 以上を"2.3リリース以降 "、他のファイルも含め、更新するたびに行う

これが大きな誤解かと思いますが、trunkの更新は、2.3リリース以降
2.4（あるいは2.4ベータ等）が出る時にのみ必要に応じてやれば良いのです。
常に本体trunkと/ja/trunkをsyncさせるような密な監視・更新は我々には不要なはずです。
従って全体の手間は、/ja/trunk を使わない場合と同等です。

ブランチのみの管理には「矛盾」と「本体リポジトリとの不整合」という
バージョン管理システムとしては喜ばしくないデメリットがあります。
手間的なメリットがない以上リスクのある我流を取り入れる理由は無いと思います。
いつかjaのリポジトリが我々の手を離れる日が来るかもしれませんが
本体と同じ通常のマナーで管理していれば未来の管理人に使い方を説明する必要はありません。

以上、皆さん、どうか永い目で見てよく考えてみてください。

tenpura

追記：
Miyoshiさん、
ミニマムな作業範疇を想定して最初の意見を言われたのだとしたら
もしかしたら考えが変わっているかもしれませんので
本件に関し改めてご意見をお聞かせ頂けると助かります。

[Takayuki Miyoshi]

miyoshi です。おはようございます。

皆さんの意見を拝見して次のような運用がよいのではないかと今は考えています。

* リリース担当は branch ごとの分担とする
* branch の担当と同様に trunk の担当も決める
* trunk の担当者が trunk から各 branch を設ける

この運用であれば、trunk -> branch の分岐の関係性が保たれ、また各担当者の分担範囲が明確で、手間もかかりません。

実際の翻訳作業は pot やコアパッケージのファイルなど外部からファイルを取り寄せて行うことになるので、各ブランチで白紙からの作業開始ということになりますから、分岐元になる trunk の中身についてはあまり考える必要がなく、極端な話中身がカラでもよいと思います。それであれば2、3個先の branch まであらかじめ作り置きしておいてもいいので trunk の担当者にとってはとても簡単です。

と、考えていますが、いかがでしょうか?

07/10/22 に tenpura <210...@gmail.com> さんは書きました:

[tenpura]

Miyoshiさん、皆様 こんばんは。

> * リリース担当は branch ごとの分担とする
> * branch の担当と同様に trunk の担当も決める
> * trunk の担当者が trunk から各 branch を設ける

このようにしたら各人の負担が軽いかもしれませんね。
よろしければ、初回 trunk は私が担当します。

> 実際の翻訳作業は pot やコアパッケージのファイルなど外部からファイルを取り寄せて行うことになるので、
> 各ブランチで白紙からの作業開始ということになりますから、
> 分岐元になる trunk の中身についてはあまり考える必要がなく、
> 極端な話中身がカラでもよいと思います。それであれば2、3個先の branch まで
> あらかじめ作り置きしておいてもいいので trunk の担当者にとってはとても簡単です。

いや、私が言っているのは
ブランチ分岐時に起る「スクラッチからの作業 ～ 完成された x.x.0」までを
通例通り、trunk で行おう、ということです。
そしてそのようにしたら、ブランチ、trunk ともに本体と整合性が取れるよ、ということです。

本体と整合性が取れているというのは、ブランチの始点と終点が本体のそれと一致していること
ja/ブランチ、trunkのどのリビジョンを切り取っても必ず合致する場所が
該当する本体ブランチ、trunkにある状態のことを指します。
スクラッチ作業開始部分をブランチに含めるとするとその始点はかなり曖昧で
場合によっては延々と本体trunkに該当する部分を内包する可能性が出てきます。
それでもいいじゃないか、という意見もあるかもしれませんが
なぜそんなことをわざわざするの？というのが私の意見です。

なんだか私だけガチガチな事を言っているようで恐縮ですが
整合性が低いと

・何かを参照する時に迷う
・迷うと時間がかかる
・迷うとミスが増える

ということを私自身が肌身を通して感じているからであって
最終的には民主主義的解決に従うつもりではおりますが
理由があって言っていることですのでもう少々考えてみてくださると助かります。

tenpura

[Takayuki Miyoshi]

tenpura さん、

僕はちょっと頭がこんがらがってきてしまったので、済みませんが実際の作業フローに落として確認させてもらっていいでしょうか。

tenpura さん案だと次のようなフローになるのかなと認識しているんですが、

0) 本体のメジャーバージョンのリリース (またはリリースの予告) が行われる
1) trunk の担当者が以下のアップデートを行ない trunk にコミットする
  a) 本体ソースまたは配布される pot から messages/ja.po を更新
  b) ja.po を翻訳、ja.mo を作成
  c) 同様の手順で messages/kubrick 下の ja.po、ja.mo を更新
  d) dist 下のファイルで変更のあったものを本体ソースから取り込んで翻訳
2) trunk 担当者が当該バージョンの branch を作成
3) branch 担当者が引継ぎマイナーバージョンリリース時の更新と tag 作成、パッケージ化を行う

この認識であってますでしょうか。

07/10/23 に tenpura <210...@gmail.com> さんは書きました:

[tai]

> 最終的には民主主義的解決に従うつもりではおりますが
tenpuraさん、ありがとうございます。私も同じです。

> 理由があって言っていることですのでもう少々考えてみてくださると助かります。
私は今までの作業経験からいってます。
まぁ、もう少し話し合いましょう。;-)
でも今晩は時間が無くなってしまったので、また明日にでも。

--
Tai
tek...@gmail.com

[Takayuki Miyoshi]

たぶんそれほど重大な相違はないように思うので、急がずじっくり話し合いましょう。皆さん全員が納得する方式がもう少しで見つけられそうに僕は思うんですよ。

この件に限らずですが、民主主義的解決(多数決?)は最後のギリギリまで残しときましょう。

miyoshi

07/10/25 に tai <tek...@gmail.com> さんは書きました:

[tenpura]

Miyoshiさん、Taiさん、ありがとうございます。
それではもう少々説明いたします。

> tenpura さん案だと次のようなフローになるのかなと認識しているんですが、
> 0) 本体のメジャーバージョンのリリース (またはリリースの予告) が行われる
> 1) trunk の担当者が以下のアップデートを行ない trunk にコミットする
> a) 本体ソースまたは配布される pot から messages/ja.po を更新
> b) ja.po を翻訳、ja.mo を作成
> c) 同様の手順で messages/kubrick 下の ja.po、ja.mo を更新
> d) dist 下のファイルで変更のあったものを本体ソースから取り込んで翻訳
> 2) trunk 担当者が当該バージョンの branch を作成
> 3) branch 担当者が引継ぎマイナーバージョンリリース時の更新と tag 作成、パッケージ化を行う
> この認識であってますでしょうか。

はい、概ねあっております。
メジャーバージョンの beta、RC も扱うのであれば、それもtrunk 担当者の分担です。
通常であれば、branch 分岐時の内容 = tag 内容 ですから
2)で、対応する tag も作成します。従ってこのタイミングでパッケージも作成可能です。

以下、理解し易いように図を作りましたのでご覧ください。
http://wp-ja-pkg.googlegroups.com/web/ja_repository.gif

図にあります、「スクラッチ作業 →（beta、RC）→ x.x.0」という部分は
branch のみ、trunk 利用どちらの管理方法でも生じるものであること、
また、trunk 利用ではここしか取り扱わない理由から、どちらの管理法でも
実質の作業分量や管理領域は同等であるということはご理解頂いた通りです。

# スクラッチ作業とは、ブランチ分岐時に生じる
# 本体trunkと前branch終端の異種系列マージ作業のことです。

要するに、「スクラッチ作業 →（beta、RC）→ x.x.0」を
trunk、branch どちらに含むの？という話なのですが
私がその部分を trunk で扱おうと言っている理由は単純に
元々その部分が、本体リポジトリにおいて
（前後 branch の領域ではなく） trunk の領域だからです。

将来的に絶対に二度と trunk を使う場面はない、と誰が今決められるでしょうか？
仮に、branch のみの管理をしていて
将来的に最新ソースの翻訳リソースも頻繁にアップデートしたいから trunk を使おう
ということになったとしたらどのようなことが起るでしょうか？
未来の管理者は本来ひと続きで過去に遡れるはずの trunk のログが、
branch と trunk にバラバラに分断されて格納されていることに気づくはずです。
そしてそのまま管理を続けると、trunk と branch の重複現象が起ります。
このような悪いシナリオが予見できるので、branch のみの管理はあまり勧められないのです。

以上、不明な点がありましたら聞いてください。

tenpura

[Mako]

前の私の投稿に対して
> branchから次のbranchは生えません。
> 「あるブランチの終端と次ブランチの頭は繋がらない」のです。
とのご指摘、そのとおりです。書いたときにも多少誤解を生むかなと思いながらもそのままにしてしまいました。私もそのことは認識しています。
前の投稿の絵を訂正すれば、
　／　　／　　／

　　　＼　　＼　　＼
のようになるでしょう。
空中から生えているように見えますが、本体の trunk を trunk として、ja にはその branch だけが見えていると考えてください。

それはさておき

> > tenpura さん案だと次のようなフローになるのかなと認識しているんですが、
> > 0) 本体のメジャーバージョンのリリース (またはリリースの予告) が行われる
> > 1) trunk の担当者が以下のアップデートを行ない trunk にコミットする
> > a) 本体ソースまたは配布される pot から messages/ja.po を更新
> > b) ja.po を翻訳、ja.mo を作成
> > c) 同様の手順で messages/kubrick 下の ja.po、ja.mo を更新
> > d) dist 下のファイルで変更のあったものを本体ソースから取り込んで翻訳
> > 2) trunk 担当者が当該バージョンの branch を作成
> > 3) branch 担当者が引継ぎマイナーバージョンリリース時の更新と tag 作成、パッケージ化を行う
> > この認識であってますでしょうか。
>
> はい、概ねあっております。

ということですので、これに従って思うところを書きます。
(一)ひとつ確認したいのは 1-a)1-c)と2)の時間差です。
1-b)1-d)の作業をtrunkで行なって一段落したところで2)が行なわれる、ということでしょうか?

(二)もうひとつ確認したいのは、2)が行なわれ3)が進行している時期の1-b)1-d)についてです。tenpuraさんの絵でこのへんは「…」で、よくわかりませんでした。
一般的な svn の流れは tenpura さんの説明でまったく間違いないと思うのですが、いまここで対象としている「翻訳」作業では、2)が行なわれた後は、見つかった翻訳間違いの修正などは専ら branch 上で行なわれ、trunk 上での 1-b)1-d)の作業はないのではないでしょうか?
2)が起こって以降の修正を trunk にする必要がないのは、次の 0)が起こると次の 1-a)1-c)で、まったく新しく本体ソースからファイルを作るからです。また、次の0)が起こる前に別の branch が生える可能性もないからです。
同じ trunk という場所で形式上は連続していても、中身に連続性はなく(その必要もなく)断絶しています。そうだとすると、前のように絵を書けば実質的には
　┌─　　　　┌─
─┘　─┐　─┘　─┐
　　　　└─　　　　└─
のようになるでしょう。

いずれにしろ、一般的な svn の流れと違ってここでの作業では断絶が起こる、 それは 1-a)1-c)を行なうからだ、ということです。
本体の trunk を本当の幹として ja にはその枝だけが見えている(最初の絵ではそのとおりですし、後の絵では trunk と呼んでいるものが本体から見て枝に当たる)と考えれば、この断絶(すきま)は本体の trunk でつながって(埋まって)いるのです。

この投稿のふたつの絵は実質的には同じで、どこで折れ曲がっているか、すなわち

> 要するに、「スクラッチ作業 →（beta、RC）→ x.x.0」を
> trunk、branch どちらに含むの？という話なのですが

です。

実質同じということであれば、私はどちらにこだわるものでもありません。ここで提示した疑問点(一)の「一段落」の判断をどうするかをもう少し具体的に書き加え(二)の「2)以降、次の0)まで trunk は特にいじる必要はない」を書き加えた上で、[wp-ja-pkg:19]で miyoshiさんがまとめられ tenpuraさんが「概ねあっている」とおっしゃる箇条書きのフローに賛成します。

[tenpura]

Makoさん、噛み砕いてくださって感謝です。

> > tenpura さん案だと次のようなフローになるのかなと認識しているんですが、
> > 0) 本体のメジャーバージョンのリリース (またはリリースの予告) が行われる
> > 1) trunk の担当者が以下のアップデートを行ない trunk にコミットする
> > a) 本体ソースまたは配布される pot から messages/ja.po を更新
> > b) ja.po を翻訳、ja.mo を作成
> > c) 同様の手順で messages/kubrick 下の ja.po、ja.mo を更新
> > d) dist 下のファイルで変更のあったものを本体ソースから取り込んで翻訳
> > 2) trunk 担当者が当該バージョンの branch を作成
> > 3) branch 担当者が引継ぎマイナーバージョンリリース時の更新と tag 作成、パッケージ化を行う
> > この認識であってますでしょうか。
>
> はい、概ねあっております。

> ということですので、これに従って思うところを書きます。
> (一)ひとつ確認したいのは 1-a)1-c)と2)の時間差です。
> 1-b)1-d)の作業をtrunkで行なって一段落したところで2)が行なわれる、
> ということでしょうか?

時間差があってもなくても、2)の時点で ja/trunk の状態が
ja/trunkからでもパッケージ化のマージが可能な完成状態になっていなくてはなりません。
そのことの内容検証はやはり複数名で行うべきでしょう。
Makoさんが気にされている「一段落」の問題点とは具体的にどういったことでしょうか。

> (二)もうひとつ確認したいのは、2)が行なわれ3)が進行している時期の1-b)1-d)についてです。
> tenpuraさんの絵でこのへんは「...」で、よくわかりませんでした。

> 一般的な svn の流れは tenpura さんの説明でまったく間違いないと思うのですが、
> いまここで対象としている「翻訳」作業では、2)が行なわれた後は、
> 見つかった翻訳間違いの修正などは専ら branch 上で行なわれ、
> trunk 上での 1-b)1-d)の作業はないのではないでしょうか?

はい、そうです。
「...」期間はほったらかしです。

> 2)が起こって以降の修正を trunk にする必要がないのは、
> 次の 0)が起こると次の 1-a)1-c)で、まったく新しく本体ソースからファイルを作るからです。
> また、次の0)が起こる前に別の branch が生える可能性もないからです。
> 同じ trunk という場所で形式上は連続していても、中身に連続性はなく(その必要もなく)断絶しています。
> そうだとすると、前のように絵を書けば実質的には
> ┌─ ┌─
> ─┘ ─┐ ─┘ ─┐
> └─ └─
> のようになるでしょう。

確かに断絶と呼べるギャップですが、そうなるのは極端に、ja/trunk の更新周期が長いからですね。
週1回か、3ヶ月に1回かといった違いです。
例えば週1回、ja/trunk を本体 trunk と sync させていたとしたら
1)では前ブランチの終端のソースを使わずに直近の ja/trunk のものを主に使うことになるでしょう。
もちろん、頻繁に更新して ja/trunk の隙間を埋めるのは自由なのですが
我々には今のところそうする必要性はありません。

tenpura

On 10月27日, 午後7:20, Mako <hange...@D.halfmoon.jp> wrote:
> 前の私の投稿に対して> branchから次のbranchは生えません。
> > 「あるブランチの終端と次ブランチの頭は繋がらない」のです。
>
> とのご指摘、そのとおりです。書いたときにも多少誤解を生むかなと思いながらもそのままにしてしまいました。私もそのことは認識しています。
> 前の投稿の絵を訂正すれば、
> ／ ／ ／
>
> ＼ ＼ ＼
> のようになるでしょう。
> 空中から生えているように見えますが、本体の trunk を trunk として、ja にはその branch だけが見えていると考えてください。
>
> それはさておき
>
> > > tenpura さん案だと次のようなフローになるのかなと認識しているんですが、
> > > 0) 本体のメジャーバージョンのリリース (またはリリースの予告) が行われる
> > > 1) trunk の担当者が以下のアップデートを行ない trunk にコミットする
> > > a) 本体ソースまたは配布される pot から messages/ja.po を更新
> > > b) ja.po を翻訳、ja.mo を作成
> > > c) 同様の手順で messages/kubrick 下の ja.po、ja.mo を更新
> > > d) dist 下のファイルで変更のあったものを本体ソースから取り込んで翻訳
> > > 2) trunk 担当者が当該バージョンの branch を作成
> > > 3) branch 担当者が引継ぎマイナーバージョンリリース時の更新と tag 作成、パッケージ化を行う
> > > この認識であってますでしょうか。
>
> > はい、概ねあっております。
>
> ということですので、これに従って思うところを書きます。
> (一)ひとつ確認したいのは 1-a)1-c)と2)の時間差です。
> 1-b)1-d)の作業をtrunkで行なって一段落したところで2)が行なわれる、ということでしょうか?
>

> (二)もうひとつ確認したいのは、2)が行なわれ3)が進行している時期の1-b)1-d)についてです。tenpuraさんの絵でこのへんは「...」で、よくわかりませんでした。

[tai]

tenpuraさん、

前後しますがご勘弁。

> もちろん、頻繁に更新して ja/trunk の隙間を埋めるのは自由なのですが
> 我々には今のところそうする必要性はありません。

端的に言って、必要がないのに私たちがトランクを使うのはWP本体との整合性のため、ということで、なぜ整合性を取る必要があるのかと言えば、後々迷ったり混乱したりしないようにするため、ということですよね？
で、私はと言えば、ブランチしか使用しないと決めておけば迷ったり混乱したりしないと思いますし、であれば必要の無い場所を使用する理由もない、と思うんです。

ちょっと戻って、

> 「あるブランチの終端と次ブランチの頭は繋がらない」のです。

branchの「途中」からなら別のbranchは生えます。
いうまでもなくtrunkやbranchの意味は、trunkが幹、branchは枝です。枝の途中から別の枝は生えます。

> # スクラッチ作業とは、ブランチ分岐時に生じる
> # 本体trunkと前branch終端の異種系列マージ作業のことです。

この実際の作業が私としては一番気になります。
ja.poは最新branchのをtrunkにコピーして、それを更新するのですよね？

> 要するに、「スクラッチ作業 →（beta、RC）→ x.x.0」を
> trunk、branch どちらに含むの？という話なのですが

> 私がその部分を trunk で扱おうと言っている理由は単純に
> 元々その部分が、本体リポジトリにおいて
> （前後 branch の領域ではなく） trunk の領域だからです。

う～ん、本体とは状況が違うので、本体と同じルールを当てはめる必要はないのではないかと思うんですよね。。

> 将来的に絶対に二度と trunk を使う場面はない、と誰が今決められるでしょうか？

もちろん、今trunkを使用しないからといって、将来も使用しないとは限りません。

> 未来の管理者は本来ひと続きで過去に遡れるはずの trunk のログが、
> branch と trunk にバラバラに分断されて格納されていることに気づくはずです。

trunk案でも継続的にtrunkを保守していない以上、ログは飛び飛びになりますし、branchで入った変更も上述のスクラッチ作業ではtrunkには残らないですよね。

> そしてそのまま管理を続けると、trunk と branch の重複現象が起ります。

すいません、「重複現象」とは具体的にどのようなことですか？

Miyoshiさん、

> * リリース担当は branch ごとの分担とする
> * branch の担当と同様に trunk の担当も決める
> * trunk の担当者が trunk から各 branch を設ける

もう少し話を続けるとして、それでもダメなら上記でオッケーです。

--
Tai
tek...@gmail.com

[Takayuki Miyoshi]

tenpura さん、ご確認ありがとうございます。

0) 本体のメジャーバージョンのリリース (またはリリースの予告) が行われる
1) trunk の担当者が以下のアップデートを行ない trunk にコミットする
  a) 本体ソースまたは配布される pot から messages/ja.po を更新
  b) ja.po を翻訳、ja.mo を作成
  c) 同様の手順で messages/kubrick 下の ja.po、ja.mo を更新
  d) dist 下のファイルで変更のあったものを本体ソースから取り込んで翻訳
2) trunk 担当者が当該バージョンの branch を作成
3) branch 担当者が引継ぎマイナーバージョンリリース時の更新と tag 作成、パッケージ化を行う

このフローの問題としては、作業の大半が trunk 担当者にかたよってしまうという点があります。tai さんが最初ローテーションを提案されたのは作業負担の分担が目的だったと思いますので、これだけだと当初の目的からずれてしまいます。

trunk の担当をさらにそのなかでローテーションするという手もあると思います。その場合は「どのようにローテーションするか」明確にルールを作っておかなくてはいけません。ただしあまり複雑なルールにしてしまうとかえって混乱をまねくことになります。

そこで僕からの提案なんですが、次のようなフローを考えてます。

0) 本体のメジャーバージョンアップのリリースが行われる
1) trunk の担当者がアップデートを行ない trunk にコミットする
2) trunk の担当者が branch を作成する [ここまでは一緒]
3) ** trunk の担当者が当該 branch の担当者になる **
   -> 引き続き branch 担当者として branch での更新、tag 作成、パッケージ化を行う
4) 次の担当者に trunk を引き継ぐ

模式図を添付しているのであわせて見てください。(各色がそれぞれ担当者)

これなら、

* trunk/branch の整合性が保たれ本体にも一致する
* 公平な分担ができる
* 責任範囲が明確

見方を変えれば作業の開始を trunk で始めるだけのことで、branch のみでの運用ともほとんど違いはありません。

どうでしょうか。

miyoshi

07/10/26 に tenpura <210...@gmail.com> さんは書きました:

[tenpura]

Miyoshiさん

> そこで僕からの提案なんですが、次のようなフローを考えてます。
> 0) 本体のメジャーバージョンアップのリリースが行われる
> 1) trunk の担当者がアップデートを行ない trunk にコミットする
> 2) trunk の担当者が branch を作成する [ここまでは一緒]
> 3) ** trunk の担当者が当該 branch の担当者になる **
> -> 引き続き branch 担当者として branch での更新、tag 作成、パッケージ化を行う
> 4) 次の担当者に trunk を引き継ぐ
> 模式図を添付しているのであわせて見てください。(各色がそれぞれ担当者)
> これなら、
> * trunk/branch の整合性が保たれ本体にも一致する
> * 公平な分担ができる
> * 責任範囲が明確
> 見方を変えれば作業の開始を trunk で始めるだけのことで、
> branch のみでの運用ともほとんど違いはありません。

ああ、これはトランク案で僕が最初に提案した形ですね。
みなさんが構わないのであればこの形で賛成します。
これなら branch のみの運用ローテーションと各人の担当期間が一致しますね。

taiさん

> この実際の作業が私としては一番気になります。
> ja.poは最新branchのをtrunkにコピーして、それを更新するのですよね？

最新branchのをtrunkにコピー、はしない方が良いと思います。
スクラッチ作業は、本体 trunk の特定のリビジョンを元に
そのほとんどが担当者のローカル環境で行われることになると思います。
ja.po に関しては最低でも、poedit等の「ソース同期」機能で
最新 branch のものと本体 trunk ソースを同期させたものを利用して
スタートするべきでしょう。

常に、本体のどのリビジョンに対しての作業か、ということを
把握していなくてはなりませんから、作業者は、subversion の
コメントに該当する本体のリビジョン番号を記録しなくてはなりませんね。
この辺りの話は「効率良い共同作業の手引書」のようなものを作って
別途話し合いましょう。

> すいません、「重複現象」とは具体的にどのようなことですか？

branch に trunk 領域を内包して管理する、trunk も更新する
という状況では重複する領域がでてしまうだろうという話です。

tenpura

[Takayuki Miyoshi]

ああ、これはトランク案で僕が最初に提案した形ですね。

そうですね :)
あとで過去メール読み返したらまったく同じことが書いてありました。
失礼しました。

最新branchのをtrunkにコピー、はしない方が良いと思います。
スクラッチ作業は、本体 trunk の特定のリビジョンを元に
そのほとんどが担当者のローカル環境で行われることになると思います。
ja.po に関しては最低でも、poedit等の「ソース同期」機能で
最新 branch のものと本体 trunk ソースを同期させたものを利用して
スタートするべきでしょう。

この点は僕は基本的に tenpura さんの考えに近いです。むしろ branch と trunk は完全に分けてあつかったほうが作業分担上わかりやすいと考えてます。branch 担当者は trunk には触れない、trunk 担当者は branch には触れない。翻訳語の統一レベルの同期は svn とは別のレイヤーで行うべきだと思います。

本体では trunk は常に次期バージョン用の branch としての扱いになっているはずです。2.3.x が最新の現在は trunk は branches/2.4 の原型になっています。trunk が branches/2.4 にコピーされた瞬間に trunk は branches/2.5 の原型になります。これと同じルールでやれば beta や RC が出たときにも誰が担当するのか明確です。

miyoshi

07/11/01 に tenpura <210...@gmail.com> さんは書きました:

[Mako]

miyoshi さんが絵を描いてくれてtenpuraさんが「ああ、これはトランク案で僕が最初に提案した形ですね。」というところまですっかり理解していたと思ったのですが (私がその前に描いた断絶のあるtrunkの絵もまったく同じつもりです)、

> むしろ branch と trunk
> は完全に分けてあつかったほうが作業分担上わかりやすいと考えてます。branch 担当者は trunk には触れない、trunk 担当者は branch
> には触れない。

というのはそれと矛盾しませんか。
私は、trunkが休眠から覚めてbranchして役目を終えるまで、私の絵で言えば分断された「かぎ形」のそれぞれ、miyoshiさんの絵で言えば色分けされたそれぞれを、ひとりの担当者とするのがわかりやすいと思います。

こう考えれば、途中で折れ曲がる以外 branchのみ案も変わりません。ですので、私はどちらでもいいです(branchのみ案の場合、下記の 1) を「担当者Aさんは、あらたな branchを作り次の作業をする。」とし、3-a)を省略すればいいだけです)が、いちおう trunk案を前提に書きます。

いくつか前に箇条書きされたものを補足して、上記の分担を明らかにしつつ1)の中を即時にできるものとしばらく時間を要するものに分けてまとめ直してみます。

0) 本体のメジャーバージョンのリリース (beta とか RC とか。またはその予告) が行われると、
1) 担当者Aさんは、休眠していた trunk に次の作業をする。
a) 本体ソースから作ったまたは配布される pot をコミット
b) 同様の手順で messages/kubrick 下の pot をコミット
c) dist 下のファイル(直接書き換えるもの)を本体ソースから取り込んでコミット
1') 翻訳作業
a) 担当者Aさんは、前の翻訳を参考に、それぞれのおおまかな日本語訳を入れてコミットし、
b) みんながレビュー、コミット権者がコミット
d) しばらく b) をループする
2) 安定してきたら(あるいは本体でパッケージリリース間近のアナウンスがあったら)、
a) 担当者Aさんはパッケージを試作し、
b) みんなで検証、コミット権者がコミット
c) しばらく a)-b) をループする
3) いよいよ最初の公開パッケージを作るときがきた(本体でリリースされた)ので、担当者Aさんは、
a) branch を作る --- この時点から trunk は休眠に入り、次の 1) まで誰も手を触れない
b) 同時に tag も作る
c) 同時に パッケージを作る
d) 一般に向けアナウンスする

これ以降、間違い等が見つかれば、担当者Aさんの下で branch の中で作業が続き、本体でマイナーバージョンのリリースがあれば 3) を繰り返す。
また、本体で次の 0) が起これば、「担当者Bさん」に読み替えてはじめに戻る。
繰り返されている 担当者Aさんの 3) と、次の0)以降(担当者Bさん)は時間的に重複する可能性がある。

[Takayuki Miyoshi]

Mako さん、

miyoshi さんが絵を描いてくれてtenpuraさんが「ああ、これはトランク案で僕が最初に提案した形ですね。」というところまですっかり理解していたと思ったのですが (私がその前に描いた断絶のあるtrunkの絵もまったく同じつもりです)、

> むしろ branch と trunk
> は完全に分けてあつかったほうが作業分担上わかりやすいと考えてます。branch 担当者は trunk には触れない、trunk 担当者は branch
> には触れない。

というのはそれと矛盾しませんか。

これは僕の説明がまずかったようです。本当は「それまで trunk 担当者であっても branch したらもう trunk には触っちゃだめ」ということがいいたかったんです。かえってややこしくしてしまいました。ごめんなさい。

僕の認識は Mako さんの書かれたフローに完全に一致です。その線でみなさんどうでしょうか。

07/11/01 に Mako <hang...@d.halfmoon.jp> さんは書きました:

[tai]

> 僕の認識は Mako さんの書かれたフローに完全に一致です。その線でみなさんどうでしょうか。

他の方がそれでいいのならオッケーです。
私にはいまだにtrunkを使用する意味が分かりませんが(^^;

tenpuraさん、

> ja.po に関しては最低でも、poedit等の「ソース同期」機能で
> 最新 branch のものと本体 trunk ソースを同期させたものを利用して
> スタートするべきでしょう。

これは例えば2.4b1リリース時

1. 作業コピーのja/trunk/ja.poをpot/trunk/wordpress.pot（もしくは本体trunkコード）で更新
2. 作業コピーのja/trunk/ja.poにja/branches/2.3/ja.poでの追加修正分をマージ
3. 作業コピーのja/trunk/ja.poにpot/trunk/wordpress.potで追加された新規翻訳文字列を翻訳

という順番ですよね？
このとき「２」のbranchでの追加修正分のマージ作業は実際にはどのように行なうのですか？
コピーペースト？翻訳メモリ機能？

Miyoshiさん、

> 翻訳語の統一レベルの同期は svn とは別のレイヤーで行うべきだと思います。

これは具体的にどのようなことですか？

Makoさん、

> a) 本体ソースから作ったまたは配布される pot をコミット

私たちがpotをコミットすることはないので、これは「本体ソースから、または配布されるpotからja.poを更新してコミット」ということですよね？

--
Tai
tek...@gmail.com

[Takayuki Miyoshi]

> 翻訳語の統一レベルの同期は svn とは別のレイヤーで行うべきだと思います。

これは具体的にどのようなことですか？

poEdit の翻訳メモリで過去例からひっぱって用語統一をはかるというのが今のところ考えつくことですが、他にもっと便利な方法がないかと考えてます。

poEdit 使ってない人もいるだろうし、翻訳メモリだと完全一致でない候補も取り込んでしまうしファジー翻訳扱いになるのでちょっと使いづらいところもありますよね。

たとえばですけど、
1) DB 上に過去の翻訳例をすべてストックしておいて、
2) 当該バージョンの POT をアップロードすると
3) ストックから完全一致した翻訳語を取り込んで POT と組み合わせ、
4) PO を出力
というようなウェブサービスを作れないかとか。テキスト処理だけなんでたぶんそんなに難しくないと思う。
 
うまくいったら報告します。

miyoshi

07/11/01 に tai <tek...@gmail.com> さんは書きました:

[tenpura]

> > 僕の認識は Mako さんの書かれたフローに完全に一致です。その線でみなさんどうでしょうか。
> 他の方がそれでいいのならオッケーです。

taiさん、ありがとうございます。
では、Makoさんがまとめられた内容に

> 私たちがpotをコミットすることはないので、これは「本体ソースから、
> または配布されるpotからja.poを更新してコミット」ということですよね？

の修正を加えた内容のフローで構成・ローテーションのおおまかな流れは決まりですね。
今後は実作業の具体的なあれこれを考えるわけですがこれが結構細かいです。

Miyoshi さん

> poEdit 使ってない人もいるだろうし、翻訳メモリだと完全一致でない候補も取り込んでしまうし

> ファジー翻訳扱いになるのでちょっと使いづらいところもありますよね。
> たとえばですけど、
> 1) DB 上に過去の翻訳例をすべてストックしておいて、
> 2) 当該バージョンの POT をアップロードすると
> 3) ストックから完全一致した翻訳語を取り込んで POT と組み合わせ、
> 4) PO を出力
> というようなウェブサービスを作れないかとか。テキスト処理だけなんでたぶんそんなに難しくないと思う。

僕も色々考えてみてますが、ファジーはファジーでいいのでは？と思うようになってきました。
既成のWEBシステムでは「Pootle」というものがあります。（使ったことはない）

ブラウザ上で翻訳ファイルが編集できるソフト「Pootle」
http://labs.unoh.net/2007/08/_pootle.html

実際に動いてるところ
http://pootle.wordforge.org/projects/ff2/

とりあえず、po ファイルに関しては svn 上で差分が汚くならないように
msgid でソートする仕組み（msgcat のような）は共有すべきかと考えています。
参考： http://makunouchi.jp/zope3/8440297694

po ファイルはまだいいとして、ソースに訳をハードコーディングする部分の管理が
どうにも修羅場ですね。

tenpura

[Takayuki Miyoshi]

ブラウザ上で翻訳ファイルが編集できるソフト「Pootle」
http://labs.unoh.net/2007/08/_pootle.html

よさそうですねこれ! 情報ありがとうございます。

サーバ立ててインストールする必要があるのか。WP プラグインとして移植したくなってきた。

miyoshi

07/11/02 に tenpura < 210...@gmail.com> さんは書きました:

[tai]

私の前回のメールの、

> これは例えば2.4b1リリース時
>
> 1. 作業コピーのja/trunk/ja.poをpot/trunk/wordpress.pot（もしくは本体trunkコード）で更新
> 2. 作業コピーのja/trunk/ja.poにja/branches/2.3/ja.poでの追加修正分をマージ
> 3. 作業コピーのja/trunk/ja.poにpot/trunk/wordpress.potで追加された新規翻訳文字列を翻訳
>
> という順番ですよね？
> このとき「２」のbranchでの追加修正分のマージ作業は実際にはどのように行なうのですか？
> コピーペースト？翻訳メモリ機能？

このマージ作業に関して「別レイヤー」や「msgid でソートする仕組み」等をお考えになっているのですよね？

ここでなぜ「ブランチのja.poをトランクにコピーしてそれを.potで更新」しないのかが私には分からないんです。
2.4b1リリース時、私の考えているのはこういう順番です：
1. 作業コピーのja/trunk/ja.poをja/branches/2.3/ja.poで上書きコピー
2. 作業コピーのja/trunk/ja.poをpot/trunk/wordpress.pot（もしくは本体trunkコード）で更新
3. 作業コピーのja/trunk/ja.poにpot/trunk/wordpress.potで追加された新規翻訳文字列を翻訳
4. コミット
これならbranchでの追加修正分のtrunkへのマージ作業は必要ありません。

> po ファイルはまだいいとして、ソースに訳をハードコーディングする部分の管理が
> どうにも修羅場ですね。

う～む、「WordPress 要日本語化本体ファイル一覧※」で確認更新時のリビジョンを記録していくだけで十分だと思うのですが。。。
※ http://groups.google.com/group/wp-ja-pkg/web/wordpress

ところで、みなさん、.poファイルの編集でpoEdit以外を使う予定の方はいますか？

--
Tai
tek...@gmail.com

[Mako]

このあと用があって出かけるので簡単に。
いくつか私への質問に答えていませんが、あとでまとめて答えます。すみません。

From: tai <tek...@gmail.com>
Date: Fri, 2 Nov 2007 18:55:53 +0900

> ところで、みなさん、.poファイルの編集でpoEdit以外を使う予定の方はいますか？

はい。
私は Linux のみを使っていて手元に Windows がないので poEdit は使いません。
道具は Emacs の po-mode です。

> このマージ作業に関して「別レイヤー」や「msgid でソートする仕組み」等をお考えになっているのですよね？

> ここでなぜ「ブランチのja.poをトランクにコピーしてそれを.potで更新」しないのかが私には分からないんです。

Windows 環境ではどうかわかりませんが、少なくとも UNIX系には msgmerge
というコマンドがあって、一発でやってくれると思いますので、それを使うの
ではないかと思います。どっちをどっちというのかわかりませんが。

私も詳しくないので、これから勉強しなければなりません。
参考: http://www.sepia.dti.ne.jp/inoue/memo/gettext.html

[tai]

> > ところで、みなさん、.poファイルの編集でpoEdit以外を使う予定の方はいますか？
>
> はい。
> 私は Linux のみを使っていて手元に Windows がないので poEdit は使いません。
> 道具は Emacs の po-mode です。

おー、そうだったんですか。でもLinuxでもたいていのディストリビューションでpoeditが使えると思いますよ。私はたまにUbuntuでpoeditを使ってます。

> > このマージ作業に関して「別レイヤー」や「msgid でソートする仕組み」等をお考えになっているのですよね？
>
> > ここでなぜ「ブランチのja.poをトランクにコピーしてそれを.potで更新」しないのかが私には分からないんです。
>
> Windows 環境ではどうかわかりませんが、少なくとも UNIX系には msgmerge
> というコマンドがあって、一発でやってくれると思いますので、それを使うの
> ではないかと思います。どっちをどっちというのかわかりませんが。

たぶんpoeditも「potで更新」のときは内部でmsgmergeを使ってるんだと思います、

私がこの質問をしたのは、もしかしたら「potで更新」が使えないアプリケーションを使っている方がいるかもしれないなぁと考えたからで、同じ機能があるのならどれでもオッケーだと思います。

--
Tai
tek...@gmail.com

[Mako]

> おー、そうだったんですか。でもLinuxでもたいていのディストリビューションでpoeditが使えると思いますよ。私はたまにUbuntuでpoeditを使ってます。

あらら、ほんとですね。
前に poEdit って何だと思って検索したときに Windows での使い方みたいなの
ばっかり引っかかったので、てっきり Windows 専用だと思い込み、
その後ろくに気にしていませんでした。
失礼しました。

[Mako]

> Makoさん、
>
> > a) 本体ソースから作ったまたは配布される pot をコミット
>
> 私たちがpotをコミットすることはないので、これは「本体ソースから、または配布されるpotからja.poを更新してコミット」ということですよね？

深く考えていません :-p

作業を、0)の時点で即座にできるものと、一定の時間幅を持つものに分けて考えました。
翻訳は時間がかかってしまうので、おおまかとは言え担当者Aさんがそれを終え
るまでみんなが手持ちぶさたになってしまうのもどうかと思い、翻訳前の pot などをコミットするとしたのです。
(今思えば、 msgmerge を使えば即座の作業ですね)

もちろん出来上がりの際にはなくてもいいのですが、作業場にあってもいいとは思います。
担当者Aさんは 1'-a) の作業をひとりでやらなくても「△△さん、このファイ
ルの分おねがい」とやることもできると思いまして。

この辺、適当に修正してください。

[Mako]

今更ではありますが、

> > (一)ひとつ確認したいのは 1-a)1-c)と2)の時間差です。
> > 1-b)1-d)の作業をtrunkで行なって一段落したところで2)が行なわれる、
> > ということでしょうか?
>
> 時間差があってもなくても、2)の時点で ja/trunk の状態が
> ja/trunkからでもパッケージ化のマージが可能な完成状態になっていなくてはなりません。
> そのことの内容検証はやはり複数名で行うべきでしょう。
> Makoさんが気にされている「一段落」の問題点とは具体的にどういったことでしょうか。

私はその時点で「なっていなくてはならない」とは思っていないのです。
私が後で書いたフローでは tenpura さんのご意見にしたがって、trunk から
branch する時期は 3-a) に置きました。

しかし、みなさんの合意さえとれていれば、その時期はたとえば 2-a) の直前
にも置けますし、極端には 1'-a)の前に置くこともできます(すると trunk の
覚醒時間はとても短くなるので、いっそなくてもいいという話になり branch
のみ案に一致します)。逆にうんと遅くして、次の 0) が起こったときにはじ
めてそれまでの trunk を branch に、という運用も考えられます。

要は何をもって「一段落」とするか、が問題だと思ったのです。
いまのところ 3-a) の位置で一応の合意が得られていると思いますが、
しばらくやってみてまた考えてもいいと思います。

[kvex]

ず～っと冷静に読めばわかることなんでしょうが、どこが決定事項でどこが未確定でどこが参考意見なのかわかりずらくなってきています。
僕が頭悪いだけ？（涙

[tai]

決定しているのは、主コミッターとリーダー、その他の受け持ちはメジャーリリースごとのローテーションにするということ、未決定なのは作業手順の詳細、という感じです。
長くなってしまってスルーしてる部分とか有るのでちょっと分かりにくいかもしれませんね（笑。

まぁコミッタ以外の方にはほとんど関係ない話なのですが、もちろんご意見をいただけるのなら大歓迎ですのでよろしくお願いします。

On Nov 15, 2007 11:21 PM, kvex <c.atw...@gmail.com> wrote:
>
> ず～っと冷静に読めばわかることなんでしょうが、どこが決定事項でどこが未確定でどこが参考意見なのかわかりずらくなってきています。
> 僕が頭悪いだけ？（涙
>

--
Tai
tek...@gmail.com