現時点でのブランチ運用の是非

[kobake]

長くなるので先に要点だけ書く

• 今の時点では（x64 のようなブランチは切らずに）master ブランチ一本の運用でやっていくのがいろいろ効率良いと思うが、どうか。皆さまのご意見を聞きたいです。

現在の状況

現在、x64 ブランチが運用されています。これは x64 対応に時間がかかることが想定され、分担の場としてブランチが必要だと判断され採用された方針です。

が、現在 x64 と master の足並み合わせで苦労されている様子がうかがえます。

さらに別件として sinst_src.zip の展開物の整備についても master とは別のブランチを切りそこで作業してはどうかという提案が出ています。

他対応についても対応時間がかかるものについてはさらに枝分かれの提案がされる可能性は否定できません。

所感

実際のところ長い時間のかかる対応はブランチを切って分担作業するのが理想ではあるのですが、今の時期に限っていうと、

• SourceForge から GitHub に移行したばかりである
• これまでの開発の停滞状況や SourceForge というレガシーな場を用いていたことにより溜まっていた負の遺産をかなりがんばって解消していく必要がある（失礼な物言いになってしまいますが、今はこれについて言及しておく必要があると判断しました。ご容赦ください）
• とにかくやることが多いので、今はスピード感を優先すべきと考えている（今のフェーズでスピードダウンすると普通に皆の気持ちがダレる）
• もともとが SourceForge 時代に (GitHub 流儀のような) キッチリ運用が行われていたものではないので、GitHub 移行をしたとはいえ、いきなり理想の運用にもっていこうとするのは（心意気は良いけど）ちょっと欲張りすぎ（時期尚早。理想運用に持っていくのはもう少し時間を経てからでも良いと思う）
• 少なくとも次バージョン（7月くらいになりそうですね）までは全部 master に入れていってしまうのが、スピード感を優先する意味ではやりやすくて良いのではないか
• master で多少不整合が出ることがあったとしても後から直せば良い
• 今のところの master の最低限度の品質は「AppVeyorビルドが失敗しないこと」「明らかに致命的な不具合が出る雰囲気は無いこと (ここは今の時点では感覚ベース程度で判断)」で良いと思う
• 実際、他のOSSプロダクトでも最新 master が不安定だったりすることはしばしばある（本当はこういう事例を持ち出して言い訳にしたくはないのですが、今は妥協の材料とさせてください）
• ただし不整合や不安定箇所があらかじめ分かっているものについては README または何かしらの手段でそれが分かるような明記をしたほうが良い（例：「x64 はまだ対応途中だから x64 ビルドは選べるけどそれの動作保証は無い」みたいな文言をどこかにいれておく等）

というところで（量が多くてすみません）、自分としては今の時点では master ブランチ一本でやる運用が良い（今分岐している x64 も対応完了を待たずに master に取り込んでしまう）と思っています。

実のところ、当初 sakura-editor/sakura#40 で自分が x64 ブランチ運用について言及したのは、「なんだか今の現メンバーのレビューの仕方を見ている限り、彼らは厳密な運用を好むだろうな」という汲み取りをした上でブランチ分けの提案（そしておまけのように master でやる選択肢もあるよという言及も入れた）をしたというのが実情です。

で、今の状況を眺めていて思うのは、上に挙げたような理由でやはり master 一本でやっておいたほうが良かったかな、と思っています。

ご意見ください

以上、自分の所感を述べさせていただきましたが、今のブランチ運用について、どうするのが好ましいか、皆さまからのご意見をいただきたいです。

これだけコアメンバーの人数がいると（喜ばしいことです）、意見の完全統一は難しいです。
方針を策定するにあたっては誰かが妥協をしていく、または全員が妥協をしていき、ベターな落としどころを探る必要があります。

良い感じに歩み寄る気持ちで方針の検討にご参加いただきたいと思っています。

　

参考までに、以下にブランチ運用に関連する発言のいくつかの引用を貼っておきます。

x64 のビルドに対応する #40

@kobake

x64 対応、分担してやれそうですか。

分担するとしたら master から x64 ブランチ切って、x64 からそれぞれ作業ブランチ切って x64 にマージする PR 出していって、ぜんぶマージされて x64 動作がうまい感じに安定したことが確認できたら master にマージする流れが良いかな、と思っています。

もしくは「x64 ビルドはまだ安定していません」という注記を README に書いておいた上で master で作業しちゃうというのもアリです。

　

@m-tmatma

分担するとしたら master から x64 ブランチ切って、x64 からそれぞれ作業ブランチ切って x64 にマージする PR 出していって、ぜんぶマージされて x64 動作がうまい感じに安定したことが確認できたら master にマージする流れが良いかな、と思っています。

はい。それでいいと思います。

#76 の対応後にやるのがいいと思います。

もしくは「x64 ビルドはまだ安定していません」という注記を README に書いておいた上で master で作業しちゃうというのもアリです。

master でやるのはやめたほうがいいと思います。

　

@kobake

x64 ブランチを作成しました。ここに変更内容を集めていきましょう。

　

[WIP] x64 作業集約場所 #86

@m-tmatma

X64 対応は完了してないですが、
x64 ブランチとmaster との同期の手間が大きいので
一旦 x64ブランチを master に マージしますか？

　

@kobake

同期の手間、大きいですか？
個人的には手間には感じてません。
どのような点で手間に感じているのかご説明いただけると納得しやすいです。

理想としては x64 対応完了してからマージするのが好ましいですが、作業の支障が大きいと感じるのであれば今の時点でマージしてしまう選択も視野に入れて良いと思います。

　

@m-tmatma

x64 ブランチがマージされていれば
#103 の対応をしたあと、#108 で不足分を対応する必要がなく、一発の対応で済みました。
#124　のテストをするときも別途ブランチが別れているために　x64 用対応をする必要があります。

単にマージするだけだといいのですが、追加対応が必要な場合に二度手間になります。

　

@kobake

そのあたりの手間は想定していたのですが、#40 の時点の議論ではブランチ運用を推したい雰囲気を察したのでブランチ運用としていました（手間がかかることは想定の上であの時点では推しているのだと捉えていました）。僕としては master でやってもブランチでやってもどちらでも良いと思っています。

選択肢としては以下が考えられると思いますがどうでしょう（以下以外の案もあればおっしゃってください）。

・手間はかかるけど現状のスタイルを続行
・x64 は対応途中であることを明示した上で今の x64 ブランチは master にマージし、x64 対応は master 上で行う>
・x64 に対するマージ条件を緩くする（approve 不要にする等）ことでマージ待ちの時間を減らす（問題ないことが自明なマージであれば自己マージを許容する）

　

sinst_src.zip を展開して登録する #133

@KageShiron

#141 を立てたのですが、古いファイルなども含まれておりmasterへのマージは中身を整理・更新してからでも良い気がします。一旦別ブランチで作業するのはどうでしょうか。

　

@m-tmatma

はい、いいです。

それならこの PRのmerge をブロックしておいてください。

既存の　sinst_src.zip　をもとにインストーラを作る対応をしておこうと思います。
installer は #141 が終わるまで artifacts に含めないほうがいいかもしれません。

[berryzplus]

master 一本化に賛同します。

理由ほ kobake さんが書かれているのと似た感じです。
ぼくがいうと棘のある言い方になりそうなので細かいことを書くのは自粛しときます。

[m-tmatma]

x64 は対応途中であることを明示した上で今の x64 ブランチは master にマージし、x64 対応は master 上で行う>

いいと思います。
x64 用の成果物のzipファイル名、zip 内部のフォルダ名に alpha とかいう文字列を
入れるといいと思います。

[kobake]

AppVeyor成果物の名前に alpha 入れるの良いですね。

git clone してきて自前ビルドする人が x64 を選んでビルドする可能性もあるので、そのあたりは README に「x64 版はまだ未完成である」ことを注記として入れるのに加えて、#pragma で x64 ビルド時メッセージにも「x64 版はまだ未完成である」ことが分かるような Warning を組み込む等の対応を自分は考えています。（現状は既存コードの Warning が出まくりますけど、それらの Warning をぜんぶ解消したとしてもまだ x64 対応完了というわけではないはずなので、対応完了までは明示的な Warning を組み込んでおくべきと考えている）

あとバージョン情報（タイトルバー表示も含む）にも alpha って入れたいですね。

[m-tmatma]

いいと思います。
x64 かどうかで条件コンパイル切らないで
別のマクロ (alpha と入れるかどうか) を用意しておいて、それを x64 のときに有効にするのが良いと思います。そうすることで必要無くなったら簡単に削除できるようにできます。

[m-tmatma]

sakura-editor/sakura#162 を登録しました。

[kobake]

皆さんご意見ありがとうございます。
今のところはなんとなく master 一本化で良いと思いました。
明日あたりにマージ準備の作業をしようと考えています。

@sakura-editor/sakura-developers 異論あれば今のうちにどうぞ。

[m-tmatma]

明日あたりにマージ準備の作業をしようと考えています。

マージ前に sakura-editor/sakura#173, sakura-editor/sakura#174 は入れたいです。

[kobake]

では明日に見送ります

[m-tmatma]

sakura-editor/sakura#131 も追加

[kobake]

sakura-editor/sakura#131 は x64 を master に統合後でも良くないですかね。
x64 が alpha 版であることが明示されていれば統合条件としては十分かと思います。

[kobake]

統合は明日以降に延ばします。

[m-tmatma]

sakura-editor/sakura#131 は x64 を master に統合後でも良くないですかね。

sakura-editor/sakura#182 を作りました。

[m-tmatma]

sakura-editor/sakura#131 は x64 を master に統合後でも良くないですかね。

sakura-editor/sakura#182 を作りました。

ちょっと勘違い。

統合後でもいいです。
この PR が入っていないと x64 版でも、C:\Program Files (x86)\sakura にインストールされてしまうという点だけです。

[kobake]

条件整ったので master <- x64 マージの PR を作成します。

[kobake]

というか既に sakura-editor/sakura#86 があったのでこれのマージをする流れとします。

[kobake]

master に x64 がマージされました。
以後しばらくは master 一本での運用とさせてください。

以下 Wiki にもその旨の記載を入れました。
https://github.com/sakura-editor/sakura/wiki/10.DevelopmentPolicy

一旦本件はクローズします。