From: "NARUSE, Yui" Date: 2011-10-19T15:07:16+09:00 Subject: [ruby-dev:44626] Re: Ruby 2.0 release plan 2011年10月18日17:43 Yusuke Endoh : > 2011年10月18日15:27 NARUSE, Yui : >> = リリースエンジニアリングチームの導入 >> >> 1.9.2 での mame さんの活躍や、1.9.3 での kosaki さんの活躍を鑑みるに、 >> 要するに一人じゃリリースは困難だと思うのです。 >> >> 一方でその場で気づいた人が backport という方針だと、今度は「フリーズ後は >> release manager の許可無く backport しないこと」の縛りが形骸化するので、 >> これを「release engineering team の許可無く」に変えよう、というわけです。 > > 話がおかしい気がするのですが、その「活躍」は backport 作業の > 話ではない気がします。私はほとんど backport した覚えがないし。 今回 kosaki さんはいくつか backport していますね。 わたしも 2 個やったかな。 > ブランチ管理とかアナウンスとかチケット処理の事務作業、つまり > リリースエンジニアリングはチーム制でやればいいと思います。 > > でも、意思決定が大きく関わること、つまりリリースマネジメント > にチーム制は向いていないと思います。指揮系統があいまいになる > ので。 「決定」をするのは一人というのには同意します。 ので、「リーダー」というか「ボス」というかそういう存在は決める必要があると思っています。 > 具体的には、「状況を見てスケジュールを見直す (バグの重大度と > 修正期間を予想してリリース延期を決める)」とか「マイルストーン > ごとにアナウンス出す (or 誰かに出せと指示する)」とか。 > 大きな機能を取り入れるかどうかの議論のファシリテートと、決定 > なんかも仕事だと思います。 スケジュールの draft を考えるとか、アナウンスを投げたり文面考えるのも 本質的には release manager の仕事である必要はないと思うんですよ。 端的に言うと、「決め」以外は個人に依存しないようにしたいのです。 > backport の話でも、バグかどうか微妙なときに判断を下す人は必要 > なんじゃないかと。 はい、「裁定者」は一人だけである必要があります。 > ただ、すでにスケジュールが決まっていて、本当に文字通り、 > 「何があろうとこの日付に出す」のだったら、リリースマネジメ > ントでやることはあまりなさそうではありますが。 > この成瀬さんのメールでリリースマネジメント半分終わりというか。 バグがどうしても取れないけどどうしよう、とかがありえるパターンですかねぇ。 http://yugui.jp/articles/633 yuguiさんが過去のリリースマネージメントをまとめていたので ついでに書いておく。 > 現状の問題は、単に Yugui さんが忙しすぎるというだけだと思い > ます。そういう場合はリリースマネージャの権限ごと他人に渡す > べきだと思います。 Yugui さんが忙しいのもそうなんですが、じゃあリリースマネージャの権限を 渡すので誰かどうぞと言われて、誰かやりますかね。 この話は、自分がやるとしたらこういうのがないとつらいって動機で振りました。 > まとめると、 > > - リリースマネージャ制度自体は今まで通りでよい > - リリースマネージャは事務作業でもっと他人を使うべき > - 判断・指示すらできなくなったらリリースマネージャを > 辞めるべき > > 少しきつい言い方になってますが、今までの Yugui さんの功績を > 否定するつもりはありません。 > redmine とか定着させたのはとてもすばらしい。 いや、まぁ、要するに Matz じゃダメだったから Yugui さんならどうかと思ったけど、 Yugui さんでも無理で、じゃあもう誰がやっても無理なんじゃね?ってのがこの話でして。 例えば mame さんかその他どなたかが 2.0 のリリースマネージャを現行制度で やるというのでしたら、それがうまくいっている間はそれで良いと思いますよ。 -- NARUSE, Yui