Yugui さん
遠藤です。

お元気そうでなによりです。


2011年10月25日0:24 Yugui <yugui / yugui.jp>:
> 良い機会なので、3年ほどやってきた過程での教訓を幾つか共有させて
> ください。

おお、ありがとうございます。



> (1) ブランチのメンテナンスをリリースマネージャがやってはいけない

完璧に同意します。やりません。



> (2) ブランチのメンテナンスは可能

「ブランチのメンテナンス = trunk の全コミットを見て、必要なもの
をバックポートする作業」という意味ですよね。


> とはいえ、途中で何度も躓きながらもそれになりにtrunkへの変更を
> レビューし、取り込む作業はできてきています。

「どんだけ時間がかかるかわからないがいつかは出来る」というのは、
リリースエンジニアリング的には「可能」ではないと思います。
まだいない未来のフルタイムコミッタを前提に「可能」というのも、
抵抗があります。

なので、全コミットを見る人を前提にすることはやめて、

  - backport ticket になったものだけ見る
  - バックポート判断は詳しそうな人に振る (なるべく作業も任せたい)

というやり方にしたいなー。と思ってます。



> (3) CIのない環境をサポートしてはいけない

そうですね。1.9 ではむやみにサポートしすぎていたと思います。


> 特定のプラットフォームで問題があるとき、問題の解決はメンテナに
> 頼るとしても、まず「問題があるということ」をリリース担当者が迅速に
> 認識しなければなりません。現在はメールによるメンテナへの連絡に
> 頼っており、メンテナからの返事が遅れるとそれだけ問題の把握が
> 遅れます。かくして、リリース直前になって把握していなかった問題が
> 浮上しスケジュールが破綻します(今の1.9.3)

なんと。そんなことになっていたのですか。

直メールでなく、ruby-core/-dev に流してくれた方がよかったかも。
1.9.2 時の私や今回の kosaki さんのように、リリースを手伝いたいと
思ってる人には、リリースのステータス・障害が見えない、というのが
相当な不満でした。(この事は Yugui さんには伝わっている気でいた)

というか、今からでも 1.9.3 のステータスを開示した方がいいです。



でも、プラットフォーム対応の問題はどうすればいいんでしょうね。
メンテナの無反応も問題ですが、FreeBSD のためにいじったら Solaris
で動かなくなった、それを直したら Windows で動かなくなった、とか
直前で連鎖する可能性を考えると怖い。
サポートプラットフォームを増やすごとに二次式的にこういう可能性が
上がるので、やっぱりあまり増やしたくない。くらいしか思いつかない。
他のプロジェクトはどうしているんだろう。



>> ブランチ管理とかアナウンスとかチケット処理の事務作業、つまり
>> リリースエンジニアリングはチーム制でやればいいと思います。
>
> もしブランチメンテナの立候補がないとすると、ではパッチレベル
> リリースをどうするかという話になります。ここで、コードレビューも
> 分散できれば良いのかなと思いました。あるバグがあったとして、
> バグの再現ケースを確実に特定すること、テストを書くこと、その
> コミットで本当にバグが直っていること、そのバグの影響などを考えて
> チェックすること、です。

実際に追試とか大変だし、プラットフォーム依存の問題は確認できない
し、チケットを作ってくれた人と担当者に任せます (分散) 。
首突っ込むのは、バックポートすべきかどうか意見がわかれて議論に
なっているときだけにしたい。


> なお、この作業にあたってnagachikaさんの
> ブログに大変お世話になっていることをお断りします。

全コミットをリアルタイムに見てる変態^H^H超人が多すぎですね。
nagachika さんと話したところ、「バックポートすべきかな?と思った
コミットを backport ticket にするくらいは余裕」ということだった
ので、これで最強です。



しかし、細かい改善点はあるものの、Yugui さんの功績は本当に大きい
と思ってます。(これまで不満ばかり強調してきたので、今更白々しい
と思われるかもしれないですが)
サポートレベルやチケット制など、リリースエンジニアリングの大筋を
確立してくれたので、基本的にはそのレールの上を走らせてもらってる
感じです。ありがとうございます。これからもよろしくお願いします。

-- 
Yusuke Endoh <mame / tsg.ne.jp>