[#44586] [Ruby 1.9 - Bug #5423][Open] readlineの入力待機中に端末のウィンドウサイズ変更すると入力内容が乱れる — Takuto Matsuu <matsuu@...>

8 messages 2011/10/08

[#44589] [Ruby 1.9 - Bug #5429][Open] 64ビットなFreeBSDのioctlでビット31が1なリクエストの時の不具合 — Makoto Kishimoto <redmine@...>

21 messages 2011/10/09

[#44604] Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...>

ささださんが既にいくつか 2.0 関連のメールを投げていらっしゃいますが、

75 messages 2011/10/18
[#44607] Re: Ruby 2.0 release plan — Yukihiro Matsumoto <matz@...> 2011/10/18

まつもと ゆきひろです

[#44618] Re: Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...> 2011/10/18

(2011/10/18 16:15), Yukihiro Matsumoto wrote:

[#44619] Re: Ruby 2.0 release plan — Yukihiro Matsumoto <matz@...> 2011/10/18

まつもと ゆきひろです

[#44627] Re: Ruby 2.0 release plan — Urabe Shyouhei <shyouhei@...> 2011/10/19

On 10/18/2011 10:16 PM, Yukihiro Matsumoto wrote:

[#44629] Re: Ruby 2.0 release plan — Yukihiro Matsumoto <matz@...> 2011/10/19

まつもと ゆきひろです

[#44631] Re: Ruby 2.0 release plan — Urabe Shyouhei <shyouhei@...> 2011/10/19

たとえば2.0の次のバージョン番号はどうしますか?

[#44633] Re: Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...> 2011/10/20

2011年10月20日3:31 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#44612] Re: Ruby 2.0 release plan — Yusuke Endoh <mame@...> 2011/10/18

遠藤です。

[#44707] [ruby-trunk - Feature #5512][Open] Integer#/ の改訂 — tadayoshi funaba <redmine@...>

13 messages 2011/10/30

[#44719] [ruby-trunk - Feature #5520][Open] Numeric#exact?、Numeric#inexact? の追加 — tadayoshi funaba <redmine@...>

13 messages 2011/10/31

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

From: Yusuke Endoh <mame@...>
Date: 2011-10-25 03:37:30 UTC
List: ruby-dev #44699
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>

In This Thread

Prev Next