From: Aman Gupta Date: 2014-01-13T16:19:43-08:00 Subject: [ruby-core:59746] Re: Ruby 2.1.0 in Production: known bugs and patches > If you have some time, can you try to reopen the issues affected, with settings changed similar to https://bugs.ruby-lang.org/issues/9168#note-5 (please set assignee to Yui NARUSE). Could you clarify the correct procedure for marking backports. Should tickets be moved to Backport21, or is simply marking them as Backport: "2.1: REQUIRED" enough? Is there a way to search for tickets with the backport field set to required? > Re. the performance patches, you recommend them for large ruby apps. What about small apps? They should work equally well in small apps. The patches combined gave us a 10% speed boost in our app. On Sun, Jan 12, 2014 at 7:54 PM, "Martin J. D�rst" wrote: > Hello Aman, > > Many thanks for your report. Great news about Ruby 2.1. > > Today is a holiday in Japan, so responses may not be that quick (or they may > be quicker because people don't have to go to work and can hack on Ruby all > day :-). > > If you have some time, can you try to reopen the issues affected, with > settings changed similar to https://bugs.ruby-lang.org/issues/9168#note-5 > (please set assignee to Yui NARUSE). > > Re. issuing a 2.1.1 release sooner rather than later, last Friday at a small > meeting/party to discuss and celebrate the 2.1 release (see , sorry, in > Japanese) we discussed the idea of publishing a 2.1.x release about every > three months, but earlier if there is a good set of important patches. Your > list may be just that. > > Re. the performance patches, you recommend them for large ruby apps. What > about small apps? > > Regards, Martin. > > > On 2014/01/13 11:29, Aman Gupta wrote: >> >> Last week, we upgraded the github.com rails app to ruby 2.1.0 in >> production. >> While testing the new build for rollout, we ran into a number of bugs. >> Most >> of >> these have been fixed on trunk already, but I've documented them below to >> help >> anyone else who might be testing ruby 2.1 in production. >> >> @naruse I think we should backport these patches to the ruby_2_1 branch >> and >> release 2.1.1 sooner rather than later, as some of the bugs are quite >> critical. >> I'm happy to offer any assistance I can to expedite this process. >> >> - Struct#send(:setter=, rhs) does not return rhs >> #9353 (r44501) >> breaks the faraday gem >> >> - Array#uniq behavior change >> #9340 (r44512) >> affects the sass gem >> >> - Timeout behavior change >> #9354 (r44517, r44518, r44519) >> #9380 (r44523) >> breaks the faraday gem >> >> - [BUG] assertion failure in socket.c >> #9352 (r44490, r44496) >> breaks the excon gem >> >> - segfault in method() usage >> #9334, #9313, #9310, #9326, #9337 >> #9315 (r44455, r44458, r44510, r44527, r44552, r44553) >> segv inside activesupport4 and other gems >> >> - Hash lookup with #hash and #eql broken >> #9381 (r44525, r44534, r44537) >> >> - bigdecimal division issue >> #9316 >> affects some payment processing gems >> workaround patch by @phasis: >> https://github.com/github/ruby/commit/1e778b3b20 >> >> - SizedQueue not working >> #9302, #9343, #9396 >> patches by @normalperson: >> https://bugs.ruby-lang.org/attachments/download/4113 >> https://bugs.ruby-lang.org/attachments/download/4140 >> >> In addition to the bugfix patches above, we're running the following >> performance patches in production. These have proven quite stable in our >> environment, so I encourage you to try them if you're running a large ruby >> app. >> >> - funny-falcon's st.c density patch >> https://github.com/github/ruby/commit/1e025cbd2f >> >> - funny-falcon's st.c pool allocator >> https://github.com/github/ruby/commit/3d37e2b5a3 >> >> - funny-falcon's method cache patch >> https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache >> proposed for trunk in #9262 >> >> - optimized Hash#[] and Hash#[]= with string literals >> https://github.com/github/ruby/commit/86946e72d7 >> merged to trunk in #9382 (r44551) >> >> Aside from the bugs above, our upgrade to 2.1 was very smooth. I'm happy >> to >> report that github.com is now running faster (and with less GC overhead) >> than >> ever before. >> >> Aman >> >