[ruby-dev:44695] Re: Ruby 2.0 release plan

2011/10/18 Yusuke Endoh <[e-mail]>:
> 現状の問題は、単に Yugui さんが忙しすぎるというだけだと思い
> ます。そういう場合はリリースマネージャの権限ごと他人に渡す
> べきだと思います。
(snip)
>  - リリースマネージャ制度自体は今まで通りでよい
>  - リリースマネージャは事務作業でもっと他人を使うべき
>  - 判断・指示すらできなくなったらリリースマネージャを
>    辞めるべき

どうも、すみません。1.9.3もリソースを十分に割けてはいませんで、kosakiさんに大幅に頼ってますね。
良い機会なので、3年ほどやってきた過程での教訓を幾つか共有させてください。

(1) ブランチのメンテナンスをリリースマネージャがやってはいけない
  * ブランチを切った後のリリースマネージャに集約する体制でとにかく1.9.1をリリースした後、特にブランチのメンテナンスをやりたがるひともいなかったので何となく続けてしまいました。しかし、ブランチのメンテナンスは結構時間を食うので次のリリース管理がおろそかになります。というか、途中何度か燃え尽きたり、1.9.3
preview1の遅れたりした原因です。
   パッチレベルリリースにあたって状況を一番よく知っているのはブランチメンテナなのでリリース管理者がブランチメンテナを兼ねるのも一定の意味はありますが、だとしても「別のブランチからのリリース」をやろうとすべきではありません。

  今にして思えば1.8の体制は良くできていました。

(2) ブランチのメンテナンスは可能
  1.9.1リリース前には卜部さんが自身の経験から、trunkから1.9へのバックポートを維持し続けるのは負荷が大きすぎないかと懐疑的な意見もくださいました。
  とはいえ、途中で何度も躓きながらもそれになりにtrunkへの変更をレビューし、取り込む作業はできてきています。

  ブランチをメンテナンスすることは可能です。前に伺った限りではmameさんはリリース後のメンテナンスにはあまり興味がないというお話でした。私も今のところruby_2_0のメンテナンスに立候補する予定はありません。よって誰かの立候補を待つか、他の方法を探る必要があります。ただ、立候補してくださる方がいれば、それは可能です。もしフルタイムコミッタが増えれば、十分すぎるほどに可能でしょう。

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


> ブランチ管理とかアナウンスとかチケット処理の事務作業、つまり
> リリースエンジニアリングはチーム制でやればいいと思います。

もしブランチメンテナの立候補がないとすると、ではパッチレベルリリースをどうするかという話になります。ここで、コードレビューも分散できれば良いのかなと思いました。あるバグがあったとして、バグの再現ケースを確実に特定すること、テストを書くこと、そのコミットで本当にバグが直っていること、そのバグの影響などを考えてチェックすること、です。なお、この作業にあたってnagachikaさんのブログに大変お世話になっていることをお断りします。

この部分を複数人で担当できればパッチレベルリリースの準備も、バグの重要性の評価とスケジュールというだけにまで落とし込めます。するとある一人が一つのブランチに張り付くまでしなくても維持できるようになることでしょう。

-- 
Yuki Sonoda (Yugui)
[e-mail]
http://yugui.jp