[#44566] [Ruby 1.9 - Bug #5386][Open] FiberオブジェクトのGC時にSEGV — Kazuki Tsujimoto <kazuki@...>
[#44581] [Ruby 1.9 - Bug #5419][Open] FileUtils.cp_rの:preserveの動作 — Masatoshi Seki <seki@...>
[#44589] [Ruby 1.9 - Bug #5429][Open] 64ビットなFreeBSDのioctlでビット31が1なリクエストの時の不具合 — Makoto Kishimoto <redmine@...>
2011年11月14日11:25 Tomoyuki Chikanaga <nagachika00@gmail.com>:
[#44604] Ruby 2.0 release plan — "NARUSE, Yui" <naruse@...>
ささださんが既にいくつか 2.0 関連のメールを投げていらっしゃいますが、
sora_h です.
On 10/18/2011 03:49 PM, Shota Fukumori (sora_h) wrote:
RUBY_VERSION の存在をすっかり忘れていました.なるほど.
まつもと ゆきひろです
(2011/10/18 16:15), Yukihiro Matsumoto wrote:
まつもと ゆきひろです
On 10/18/2011 10:16 PM, Yukihiro Matsumoto wrote:
まつもと ゆきひろです
たとえば2.0の次のバージョン番号はどうしますか?
2011年10月20日3:31 Urabe Shyouhei <shyouhei@ruby-lang.org>:
In message <CAK6Hhsqwv0wh8OVBb3Z5BQrh3-7dLHhL-pXvW+CBv8U1rayYZg@mail.gmail.com>
なかだです。
まつもと ゆきひろです
On 10/20/2011 01:45 PM, Yukihiro Matsumoto wrote:
まつもと ゆきひろです
(2011/10/20 13:36), Yukihiro Matsumoto wrote:
まつもと ゆきひろです
(2011/10/20 23:36), Yukihiro Matsumoto wrote:
遠藤です。
2011年10月18日17:41 Yusuke Endoh <mame@tsg.ne.jp>:
遠藤です。
2011年10月18日17:43 Yusuke Endoh <mame@tsg.ne.jp>:
遠藤です。
まつもとさん
まつもと ゆきひろです
遠藤です。
[#44680] [Ruby 2.0 - Feature #5454] keyword arguments — Yusuke Endoh <mame@...>
[#44688] [ruby-trunk - Bug #5475][Open] r33507以降SolarisでPTYが使えない — Naohisa Goto <ngotogenome@...>
MjAxMRskQkcvGyhCMTAbJEI3bhsoQjI0GyRCRnwbKEIxNjo1NiBOYW9oaXNhIEdvdG8gPG5nb3Rv
On Mon, 24 Oct 2011 18:43:39 +0900
[#44702] Re: [ruby-cvs:40712] nobu:r33534 (trunk): * configure.in (RUBY_FUNC_ATTRIBUTE): unset temporary variable. — Tanaka Akira <akr@...>
2011/10/27 <nobu@ruby-lang.org>:
boronのお守りをしている西田です.
2011年10月27日19:54 Yuya.Nishida. <yuya@j96.org>:
[#44707] [ruby-trunk - Feature #5512][Open] Integer#/ の改訂 — tadayoshi funaba <redmine@...>
まつもと ゆきひろです
遠藤です。
[#44713] Re: [ruby-changes:21512] akr:r33561 (trunk): * configure.in: check dup3. — KOSAKI Motohiro <kosaki.motohiro@...>
(ruby-devへ河岸をうつします)
[#44719] [ruby-trunk - Feature #5520][Open] Numeric#exact?、Numeric#inexact? の追加 — tadayoshi funaba <redmine@...>
[#44720] [ruby-trunk - Feature #5521][Open] Numeric#rational?、Numeric#complex?、Numeric#float? の追加 — tadayoshi funaba <redmine@...>
まつもと ゆきひろです
むらたです。
[#44734] IO.select timeout — Tanaka Akira <akr@...>
気がついたのですが、IO.select で、timeout を使ったとき、
> 気がついたのですが、IO.select で、timeout を使ったとき、
[#44735] [ruby-trunk - Feature #2968] 数値の正負を返すメソッド — Kenta Murata <muraken@...>
[ruby-dev:44699] Re: Ruby 2.0 release plan
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>