Re: ブランチ間のマージ方針について

[Jiro Matsuzawa <jmatsuzawa@xxxxxxxxxxxxx>]

松澤です。

2011/11/29 Yasumichi Akahoshi <yasumichi@xxxxxxxxxxxxx>:
> 　はい、作業手順についてです。自分で勉強しろということになるかもしれませんが、
> 具体的に何が行われるかと言う所が見えて、実際に自分で体験してみてみないと問題
> があるのか、ないのかも分からないというのが本音です。

手順の説明を簡単にしようかと思いましたが、それはまた別途まとめるとして、
私が懸念していることをちゃんと伝えきれていないようなので、
改めて、その辺を説明させてください(ご面倒で本当に恐縮です)

まず、結局何を話したいのかというと、
1. マージ方針を明文化したい
2. マージ作業を楽にしたい
ということです。
1 については、とくに異論もないでしょうし一時的にスキップします(また別途)。
(暗黙でやれなんて主張する人はいませんよね・・・)

で、2について私があまり触れていないので、松澤が何を言いたいのかよくわからないということもあると思います。

ちょっと例をあげてみますが、
masterとstableとでそれなりに分離が進んで、かつ翻訳者が、
* master固有の新規メッセージの翻訳も
* 既存からの未訳箇所やfuzzyの対処も
* 既存部分の誤字誤訳の修正も
* 既存部分の訳語改善も
全部一緒くたに翻訳率100%でmasterにアップロードした場合を考えてみてください。
実際によくあるケースだと思います。

この場合に、たとえば誤訳修正はどう扱いましょうか。
stableにマージしますか、それともしないほうがいいでしょうか。
誤訳をバグと捉えるなら、まだマイナーリリースのあるstableには、誤訳修正をマージした方が良いと私は考えています。
(リリースが無いであろうold-stableは対象外)
いまのところマージ作業のコストはコミッターが負っているので、
マージ作業が発生するなら、それが機械的にできると助かります。
マージの必要なものを手動で判断してマージするとなると、かなりの手間になります。
コミット数が大きくなると、最悪のばあい捌ききれなくなることも想像できます。
# リリース前などはマージを考えないコミット作業だけでも、わりと大変だったりします・・・

捌き切れないばあいに、ものによってマージしてたり/してなかったりと、扱いが一貫していないのもあまり良い状況ではないと思います。
なので、できるだけマージ作業のコストを減らすことができればチーム全体としても望ましいかなと思います。

で、じゃあその方針や手順はどうするの、という話をしないといけませんが、
いろいろ詰め込むとまとまらなくなるので、また別途ポストさせていだきます。。
とりあえず、こちらの問題意識を掴んでいただけば幸いです。


-- 
Jiro Matsuzawa
E-mail:
  jmatsuzawa@xxxxxxxxxxxxx
  matsuzawa.jr@xxxxxxxxx
GPG Key ID: 0xECC442E9
GPG Key Fingerprint: E086 C14A 869F BB0E 3541 19EB E370 B08B ECC4 42E9