x64 作業集約場所：2018-06-27 をもって master に統合する

[kobake]

本 PR の目的

• x64 に集約されたコミット内容 (コミット群, master との差分等) を俯瞰するための場所です。
• x64 対応が一通り済んだら、この PR のマージにより master に対して x64 全変更内容を適用します。

x64 対応の作業について

• 本 PR (x64 ブランチ) に対して直接コミットを積むようなことは原則しません。
• x64 ブランチに対してコミットを積みたい場合は x64 ブランチから派生した作業ブランチ (fork 推奨) を作成し、x64 に対する PR を作成してください。
• fork したリポジトリで作業する場合は、作業する前にfork したリポジトリおよび x64 ブランチを最新にしてください。

fork したリポジトリを最新にする方法 (以下のサイトの説明にはないですが、最後に自分の fork リポジトリに git push する必要があります。

• http://d.hatena.ne.jp/nishiohirokazu/20120218/1329526827
• https://qiita.com/icb54615/items/3544c419a3f6fc3534fb
• https://help.github.com/articles/syncing-a-fork/

作業が重複しないように、着手済みの作業は分かりやすいように宣言しましょう

• 複数人による分担作業が想定されます。作業被りを防ぐため、何らかの作業に着手する際にはそれが分かるように Issue を立てる等してください（単に Issue を立てるだけでなく、着手済みが分かるような記載をしてください。記載方法は各自おまかせでよしなにやりましょう）

例

• [x64対応] (着手済) バージョン情報ダイアログに 32bit / 64bit の表示を入れる [x64対応] バージョン表示に 32bit / 64bit の表示を入れる #87

x64 関連は x64 のラベルをつける

x64 x64 対応

[m-tmatma]

fork したリポジトリで作業する場合の注意、参考情報を説明欄に追加しました。

[m-tmatma]

着手済みが分かるような記載をしてください。

Assignees に自分を割り当てればいいのでは?

[m-tmatma]

Assignees に自分を割り当てればいいのでは?

そうすれば
https://github.com/sakura-editor/sakura/issues
の画面でフィルタリングすることもできます。

こんな感じ
https://github.com/sakura-editor/sakura/issues/assigned/kobake

[kobake]

着手済みが分かるような記載をしてください。

Assignees に自分を割り当てればいいのでは?

Assignees を設定すること自体は良いと思います。

ただ、本来の Assignees の意味合いとしては着手済みかどうかというよりも
「着手する予定」「着手してもらう予定」「着手してもらいたい」「着手済み」いろんな解釈ができるので、今回は明示的に「着手済み」が分かるようにしたかったという意図があります。

ラベルで管理する選択もありますが、今回の x64 対応ぐらいでしか着手済み状態の管理ってやらなそうなので、タイトル記載で済ませられる範囲と考え、タイトル記載で済ませてます。

[m-tmatma]

x64 のラベルを作りました。
x64 x64 対応

[m-tmatma]

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

[kobake]

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

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

[m-tmatma]

同期の手間、大きいですか？

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

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

[kobake]

同期の手間、大きいですか？

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

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

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

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

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

[kobake]

↑Issue番号打ち間違えたのでコメント修正

[m-tmatma]

どうでもいいですが、この PR の番号が 86 になっている (x86 を連想)

[kobake]

現時点でのブランチ運用の是非 #3 の提案に伴い、x64 ブランチを master へ一旦マージし、以後しばらくは master で作業します。

@sakura-editor/sakura-developers
どなたか approve と merge をお願いします。
x64 ブランチ（動作検証済み）からの単純なマージですので、レビューは不要です。

マージ後のイメージは #183 となります。

仮にこのマージで後から問題が発生することがあったとしても事後対応で良いでしょう。
今のフェーズではその程度の品質で良いです。作業効率を優先しましょう。

[m-tmatma]

マージしました。