Sakura: sourceforge.netにあるパッチの適用方法

[berryzplus]

sourceforge.netに上がっているパッチを適用する方法について提案します。(関連: #45)

パッチというのはここにあるパッチのことです。
https://sourceforge.net/p/sakura-editor/patchunicode/

現状で100個くらいの未適用パッチが積まれています。
内容にもよりますが、大半はそのまま使えるパッチだと思っています。
使えるものは活用しないともったいないです。

今回、一般掲示板に「エアロスナップ対応」をなんとかしてほしいという書込みがあり、
ここのパッチを適用するとしたら具体的にどうしたらいいんだ？という疑問がわきました。

なんとなく、こうしたらいいんじゃね？と思ったことを書いてみますので、
疑問点・改善案などありましたらコメントいただけると幸いです。

作業の流れ

1. 懸案のパッチファイルをticketsページからダウンロードする
2. ダウンロードしたファイルからパッチのベースrevを確認する
3. SVNで該当revを落としてくる
4. SVNリポジトリにパッチを適用する
5. GITリポジトリのログで該当revのコミットを探し、そのコミットで作業ブランチを作成する
6. SVN→GITのフォルダ間でdiffをとって差分をGIT側に適用する
7. GITリポジトリで変更をコミットする（掲示板のポスト日時、投稿者名で代理コミット）
8. GITリポジトリのログで該当revの次～最新コミットを選択し、作業ブランチにマージする
9. ローカルでビルドしてみて、問題があれば最小限の修正をする（修正は代理でなく自身のコミット）
10. 作業ブランチをGitHub上の適当なリポジトリにPushする
11. プルリクエストを送る
12. ReviewとReview結果への対応は通常通り行う（修正は代理でなく自身のコミット）
13. 問題が解決したらマージする

書き出してみると作業項目多いなぁ～～～。

[m-tmatma]

GITリポジトリで変更をコミットする（掲示板のポスト日時、投稿者名を偽装する）

git commit --author を使うと、"Author" を設定できるみたいです。

git では コミットした人(Committer) と作者 (Author) を別に管理できるみたいです。
http://y-ken.hatenablog.com/entry/git-commit-as-different-user

時刻に関しても同様のようです。
https://alexpeattie.com/blog/working-with-dates-in-git

"偽装" というのが、上記のことを意味していたら蛇足かもしれませんが。

[m-tmatma]

現状で100個くらいの未適用パッチが積まれています。

パッチの適用状況 (パッチの番号、適用済みかどうか、対応するチケット番号、プルリクエスト番号) などがWiki で一覧で確認できると便利だと思います。

[berryzplus]

git commit --author=xxx --date=xxxx
とするつもりでした。
gitについて実はそれほど詳しくないので、言ってることが同じかどうか判断できないです(^^;

ためしにやってみた感じ、エアロスナップ対応は競合もなくマージできそうです。
https://ci.appveyor.com/project/berryzplus/sakura/build/1.0.17
https://ci.appveyor.com/project/berryzplus/sakura/build/1.0.17/artifacts

[berryzplus]

あ、GitHub上でテストしたから自動で関連リンクが表示されるんですね。便利。

[KENCHjp]

＞パッチの適用状況 (パッチの番号、適用済みかどうか、対応するチケット番号、プルリクエスト番号) などがWiki で一覧で確認できると便利だと思います。

せっかくのチケットなので、sf.netをそのままつかう案を考えてたのですが、
その場合、sf.netにアカウントないとだめですよね。
OSDNの佐渡に相談すると未クローズのパッチをOSDNに移行してもらうか、うまい具合にWiki化データ作ってもらえるかも（かなり他力）。

[m-tmatma]

せっかくのチケットなので、sf.netをそのままつかう案を考えてたのですが、
その場合、sf.netにアカウントないとだめですよね。

できれば GitHub 内で閉じるようにしたいです。
sourceforge も、OSDN もアカウント作ってないです。

OSDNの佐渡に相談すると未クローズのパッチをOSDNに移行してもらうか、うまい具合にWiki化データ作ってもらえるかも（かなり他力）。

CSV とかでエクスポートできたらいいのですが。

[KENCHjp]

なんとか、Excelにもってこれたので、csvにエクスポート出来そう。
Wikiの文法に簡単にできればいいのですが。

[KENCHjp]

,URL,Summary,Status,Owner,Created,Updated,

1117,https://sourceforge.net/p/sakura-editor/patchunicode/1117/,CShareData::InitShareData を整理して次の変更にそなえます。,open,,2018/4/24,2018/4/24,
1116,https://sourceforge.net/p/sakura-editor/patchunicode/1116/,CFileNameManager::GetIniFileName の問題含みの仕様を正します。,open,,2018/4/24,2018/4/24,
...105件
こんな感じのデータ作れました。

[m-tmatma]

以下のようにすれば Wiki で表を作れるみたいです。
https://qiita.com/risagon/items/7d75c221d672b94d4481

[KENCHjp]

@m-tmatma とりあえず、置くだけ置いてみました。
https://github.com/sakura-editor/sakura/wiki/SourceForge.net---PatchUnicode---Open-Tickets
Patchの番号をリンクにするとよさげなのですが、よくわからなかったのでとりあえず張った状態です。
すいません。

[KENCHjp]

Edit ModeをCreoleにしてます。

[berryzplus]

おお、すごいのできてる！@KENCHjp さん お疲れ様です。

1019のjs高速化ですが、最近SVNにコミット入ったような…
と思って開いてみたらコミット済みと書いてありました。
未クローズでも対応済みのものが他にもあるかも知れません。

[m-tmatma]

Edit ModeをCreoleにしてます。

すみません。Markdown のつもりで編集したら表示が壊れてしまってのでもとに戻しました。

[KENCHjp]

Excelに表で貼り付けて、そのままネットのサービスでWikiの形式にしたのですけど、GitHubのWikiのどれでやってもうまく表にならなくて、Creoleで何とか張り付いたみたいな(笑)
突貫工事なのでご容赦をm(_._)m

[KENCHjp]

ハイパーリンク化とMarkdownってのにしてみました。

[kobake]

諸々情報整理ありがとうございます。
自分としてはパッチ適用については要望の強いものが一個一個手動 Issue または PR で挙がってくることを想定していました。

パッチ同士の挙動の相性とかコード変更部の衝突とか考えると、機械的な判断で取り込んでしまうと、他機能を壊すということにもなりかねないので慎重にやっていきたい気持ちです。

とはいえあまり時期が遅くなりすぎるとディレクトリ構造変更等の影響でパッチを当てにくくなるのも確かなので、取り込みたいパッチは早急に取り込んでしまったほうが本リポジトリの変更影響受けにくくする意味では安全です。

投稿者名を偽装

偽装は響きが良くないので「代理コミット」みたいな言い方をしていただければと。
代理コミットは特段変わったことでもなく、自分以外の人のコミットが含まれるコミット群を自分で rebase したりしたときにも同じような代理コミットの処理が走ります。

[berryzplus]

はぅ、Owner欄に入りきらない悪寒...
←HN長い人
https://github.com/sakura-editor/sakura/wiki/SourceForge.net---PatchUnicode---Open-Tickets

冗談はさておき。
リストにはすぐに消し込みできるものも含まれていると思います。
消し込みをして、終わったもの／終わってないものに一旦分けませんか？

手順の中にあった「偽装」は代理コミットの表現に差し替えました。

[kobake]

リストにはすぐに消し込みできるものも含まれていると思います。
消し込みをして、終わったもの／終わってないものに一旦分けませんか？

賛成です。手間でなければ。

手順の中にあった「偽装」は代理コミットの表現に差し替えました。

👍

[KENCHjp]

Owner欄
文字が入れば伸びるのよ。。。。って冗談はさておき。
パッチは有益だと思うので、現存コミッターで取捨選別していただければと。

[KENCHjp]

@kobake さん
＞機械的な判断で取り込んでしまうと、他機能を壊すということにもなりかねないので慎重にやっていきたい気持ちです。

これは同感です。とりあえずこのWikiページは端から端から作業リスト的に消し込んでいくというよりは、ステータス管理備忘録的な位置づけでこっちのメンバーで情報共有できればなと思っております。

取り組むときには先にIssueに宣言してからスタートみたいな感じっすかね。複数人で作業重複してももったいないし。

[kobake]

取り組むときには先にIssueに宣言してからスタートみたいな感じっすかね。複数人で作業重複してももったいないし。

Issue 作成をスキップしていきなり PR 飛ばすというのもアリといえばアリです。

「この件に着手しているよ！」という情報だけ先に示す方法として WIP (Work in Progress) の PR を飛ばすという方法があります。WIP は文字通り「作業中」を示す言葉で、とりあえず途中経過でも良いので先に PR 上げちゃうときとかに使います。

いきなり完成形の PR を作ろうとすると他の人の着手と被ってしまう可能性はありますが、WIP PR を作った上で、その PR 番号を作業リストに併記するようにしておけば、間違えて他の人が同じ作業に取り掛かってしまうことは避けられるかと。

もちろん Issue のも意味はあって、いきなり PR 作成できるほどの自信はないけど、「このタスクは重要そうだから取り込んで欲しい」みたいな意図を先に伝えておく用途、または「このタスクは重要そうだけれど、何か議論の余地があれば PR 対応前に話し合いをしておきたい」とき等に活用するのが良いと思います。

[KENCHjp]

@kobake さんへ
了解です。日々勉強です。

[m-tmatma]

PatchUnicode の適用状況を追加するプルリクエストを投げました。
sakura-editor/sakura-editor.github.io#13

[kobake]

https://github.com/sakura-editor/sakura-editor.github.io/pull/13

列の順番はいかがでしょう？、肝心の情報が横スクロールしないと見えないので順番変えるかいっそsf.net側の情報はいくつか削ってしまうか。
作業は自宅に帰ってからになるので直すのは遅くなってしまいますが、Excelから張り付けなおしたほうが簡単かなと思うので。

無理にWikiをがんばって使わなければならないかというとそんなことはなくて、Googleスプレッドシートで管理する選択もあります。どうでしょう。
Wikiからはシートへのリンクを張るような感じで。

[kobake]

sakura-editor/sakura-editor.github.io#13 に書いた内容ですが、以下URL変更を行いました。

https://github.com/sakura-editor/sakura/wiki/SourceForge.net---PatchUnicode---Open-Tickets
↓
https://github.com/sakura-editor/sakura/wiki/SourceForgePatches

[KENCHjp]

@kobake さん
おおなんとなくissueとPRの位置づけを理解し始めたところです^^;
＞無理にWikiをがんばって使わなければならないかというとそんなことはなくて
それはそうっすね。もともとは情報をメモ的にGitHubに寄せたいってことからスタートしてのWikiなのでこのWikiを頑張ってメンテする必要はないと思っております。
外にだすなら逆にsf.netのチケットそのまま使った方がいいかなというのが私の意見。

[kobake]

sf.net のチケット一覧って任意カラム追加できたりしますかね。GitHub 側の Issue や PR の番号を書き込める場所 (欲を言うと備考欄も欲しい) が作れるのであれば sf.net のままで良いと思いました。(sf.net 側の仕様をあんまり分かってません……)

[KENCHjp]

この前設定画面見たのですがカラムの追加はできそうでした。
ただ一覧に反映できるかは未確認。

[KENCHjp]

そっちはそっちでやってみますかね。

[KENCHjp]

カラム追加の暁にですが、
berryzplus さんはsf.netのアカウントもってるすかね。
であれば、いったんsf.net側を振るいにかけて、残ったのをgithubのissueかPRにいれたら、sf.net側はそっと蓋を閉じれるかもですね。

[KENCHjp]

一覧にカラム追加出来なかったときの逃げ案備忘。
ステータを以下追加
wip:調査中
issue:Github issueに投げた。
PR:github pull Requestに投げた。

[KENCHjp]

なんかできたみたい。

通勤中にできるのはいいっすね。

[KENCHjp]

ステータスも追加しましたがもはや使わないステータスはバッサリ消したほうがいいかなとか。。。

[kobake]

カラム追加されましたね～良い感じです！

使ってない定義値は消しちゃって良いかと！（過去チケットで少しでも使われていると消せない可能性ありそうですが）

パッと見で気になったこととしては、一覧での Owner カラムが意味をなしてないように見えたので消せるなら消しても良いかなと思いました。Owner よりもむしろ Creator を見たいです（見れるようにできるのであれば）。

[KENCHjp]

Owner欄消してCreator欄出るようにしました。
ステータスは項目をスペース区切りで並べてあるだけなので、スマホでやるのが怖いのであとからちょっと慎重にやります。
GitHubに投げたらsf側はクローズ扱いになるようにステータス設定しようと思ってます。

[kobake]

ご対応ありがとうございます。良い感じです！
スマホからのご操作お疲れ様ですｗ

[berryzplus]

代理PRを送りました。

方法論は一旦確立できたような気がします。
残りのパッチ適用についてはwikiに引き継ぎして、ここは閉じてもいいでしょうか？

[KENCHjp]

私はOk.です。

[kobake]

この Issue についてはパッチの適用方法が wiki に記載されたらクローズ、くらいが良いのでは。

[m-tmatma]

この Issue についてはパッチの適用方法が wiki に記載されたらクローズ、くらいが良いのでは。

はい。そう思います。

[berryzplus]

この Issue についてはパッチの適用方法が wiki に記載されたらクローズ、くらいが良いのでは。

はい。そう思います。

よし、wikiに書くぞ・・・

[berryzplus]

モチベーションが尽きたので閉じてしまいます。 #1394