Robot で動作する workspace update スクリプトの挙動についての議論

[sktometometo]

#1808 での議論を受けて、各ロボットで用意するといい workspace update スクリプトの仕様について議論したいです。

@k-okada @mqcmd196 @tkmtnt7000 @nakane11

参考:

• TODO

[sktometometo]

#1821 (comment)

についてなんだけど、これは僕の想定が甘くてcommitはしたけど push していない branch が体内にあることは考えていませんでした。commitしていない変更については stash するようにしているはず。

[sktometometo]

@mqcmd196

[sktometometo]

update_workspace.sh のデバッグが結構大変で (特に rebase で divergeした際に勝手に修正する機能) あんまりいろいろなケースは想定していませんでした、他に問題になっているor使いづらい部分はなにかありますか？
@mqcmd196 @tkmtnt7000 @nakane11

[mqcmd196]

jsk_robot/jsk_robot_common/jsk_robot_startup/scripts/update_workspace_main.sh

Line 83 in 1cddbe0

wstool foreach -t $WORKSPACE/src --git 'git stash'

確かに大丈夫な気もする．ちなみにこれだと未追跡ファイルがあるとstash失敗する気がするので，git stash -u が正解ですね．

@tkmtnt7000 だとするとなんで変更が完全に消えちゃうんだっけ？

[tkmtnt7000]

先ほどのオフラインでの僕の伝え方が悪かった気もするのですが、
少し特殊ケースで、変更が消えると考えられるのは誤ってdevelop/fetchなどのrosinstallで設定されたブランチにロボット体内でローカルコミットだけ残した場合です。コミットしていないdiffはstashされて残っていると思います。

[mqcmd196]

なるほど完全に理解しました．だとするとこれは develop/fetch-patch1 みたいに退避されればよい？

[sktometometo]

それが良さそう

[tkmtnt7000]

それで回避できると思います

[mqcmd196]

とりあえずこれは今作業します

[sktometometo]

#1808 (comment) での岡田先生のコメント

結局どうなったのかな。

1. diff があったら伝えてほしい
2. build が通るか確認してほしい
3. 最新のbranchをmerge してほしい

という目的があるとして

1. はできるとして、diff があったときに reset hard するか stash するか 放置するか
2. は出来るとして、エラーがあったらどうするか？　→　人出で直す
3. は出来るとして、 merge 失敗してコンフリクトしたらどうするか？　→　元に戻るか

常時デモが動くのは良いことなんだけど、一方でデモは毎回進化していってほしいという事があります。ここがむつかしい。 今回困ったのは、前日にデモを確認して、当然、デモの度に進化させるのが至上命題なので、何か気が付いたことはさっとプログラムを修正するんですが、その修正しても、翌日の3時にリセットされると思うと結局いじれないのと、jsk-ros-pkg/jsk_pr2eus#495 でプルリクエストが出ているけど、出しただけでどこにも反映されていないので、なにか良い方法がないか、というのが話の始まりでした。 そう考えると午前3時に毎日リセットされてしまう、というところを何とかならないか、と思ったという事かな。cron変えればよい、という話も出ているけど、次の日に10時からデモで、夜中の11時にプログラム書いていて、いいでもできた、と思ったときに、Cron間違えたり忘れると朝の3時に全消しになるリスク、とういのは、かなりの恐怖ではないかな。

他の案で思いつくのは、

1. プルリクエスト出したら developにもマージするべきだった？
2. 自分のワークスペースで作業すればよかった？ちなみに、最初にデフォルトで上がるWorkspaceを変えて運用する方法を定着させて、~/fetch/ros (?) 出ない場合は特殊モードでWarningをメールなり起動音なりモニタなりで表現する？デモの前や集中実験期間はこちらで各自のプログラムが動く

ですが、現状でreset --hard がやりすぎなだけかと思ったのですが、意図はgit dirtyな状態を許容するのではなく

1. dirty な状況が送られてくる→誰かが頑張ってデバッグなり新機能の開発をしていることがわかる
2. dirty な状況が送られ続けてくる→良いところでPRを出せなくなっているOR放置している。→メールがき続けることで本にへのプレッシャーとなってほしい
3. よくわからないdirty が残っていて、何か行われている様子が無い。あるいは本人から連絡がない。そういう時はgit reset --hard することはOKという事でみんなで許容する。

でよいのでは？と思ったんだけど３）は発動されずに、結局diffが残り続けるのかな。あるいはreset hard した時にプログラムが動くことが保証されていない？大体OKだけど、hardして戻ったときのcommitだと、その時点の古い外部依存ライブラリでしかコンパイルしていないから、その途中で外部依存ライブラリがupdate されたらコンパイル通らない、というケースがあるかな。

[sktometometo]

@k-okada

Diffがあったら伝えるという機能は #1808 で追加されました。これそのものはとても便利だと思います。

もともとの開発フローの想定としては、体内で試した変更も全て Pull Request にした上で develop/fetch にマージするという運用方針でした。変更は全て develop/fetch にマージされている想定なので毎日 update_workspace.sh で最新の develop/fetch に整えるようにしていました。

これは適当にコミットされたりcommitされていない変更が放置されていると他の人が使いたいときにどういう状況かわからなくて弄れないために実験なり開発なりが出来ない状況を防ぐ意味で役に立っていると思います、また他の人がどのような開発をしているかがgithub上で可視化されるという意味合いも有りました。

ただ、これは開発フローをきちんと共有しないと開発に参加できないという問題もあると思いますし、これらのシステム群の扱いになれていない人には難しいかもしれません。今までは @knorth55 @708yamaguchi @iory あたりがどう開発するかについて手取り足取り見ていたのでどうにかなりました、これに関しては今までは口頭でのみ伝えられていたものを #1821 のような形で明確にすることである程度共有可能かと考えています。
ただ、B4が文書だけ読んできちんと開発フローに従って開発してもらうのは少し難しいかもしれません。

また develop/fetch にpushはしたくないけどある程度の期間実験をしておきたいときにどうするかは今まで想定されていなかったのでどうするべきかは考えておく必要が有りるかと思います。
今の update_workspace.sh でも ブランチを他で切ってやれば削除される挙動はないですし、 cronを切ればそのままにはなるのである程度運用でカバー出来る話では有ります。