Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 3.2.13 - Performance regressions and major bugs

blog.bugsnag.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Rails 3.2.13 - Performance regressions and major bugs

#61

Post by damoncali »

sergiotapia wrote: post #12
Axsuul wrote: post #10

Earlier quoted context omitted.

Would you really be willing to give up the productivity benefits and developer happiness over a few mishaps? Also, it's generally a good idea not to upgrade to the next software version until seeing the repercussions its had.

That's the thing! I find myself ping-ponging in my mind between "But Ruby and ActiveRecord are so beautiful and easy to use." and "But what happens if the 'magic' breaks?" Trust me, I have been thinking about what you say every day for the past 5 days.

You're thinking too much. Unless it's a "the world is ending" level security fix like the recent yaml stuff, wait a couple weeks for this stuff to come out and get fixed. Then upgrade.

Re: Rails 3.2.13 - Performance regressions and major bugs

#62

Post by rst »

timdorr wrote: post #59
jrochkind1 wrote: post #18

Okay, some of these problems are (unintended) direct side effects of the security fix bugs. Like I the one about scopes that effected Github -- github quoted [this commit]( https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5... ) as introducing the bug, which is the commit meant to address CVE-2013-1854. So, okay, bugs happen, even with security fixes, I can forgive bugs. But others of those performance regr…

This is a weird comparison, but they should adopt the same release policies as Drupal. Security releases are done separate from maintenance releases, even if they are released at the same time. That allows you to provide the security releases as a separate patch file so you can apply individually. You can skip maintenance releases that cause problems but still keep things secure.

Here's a pointer to the security fixes in the release as a monkeypatch to 3.2.12, without any of the other cruft:

https://github.com/discourse/discourse/blob/master/lib/freed...

The discourse folks who threw this together have an app (Rails-based forum software) that was hit very hard by the performance regressions.

Re: Rails 3.2.13 - Performance regressions and major bugs

#63

Post by erydo »

martinced wrote: post #58

I'm sure that Rails is great and powers many websites and that many devs loves it. I'm also sure that people are working hard to fix these recent security issues and perfs issues. But as a non-Rails dev I can tell you one thing: with all the attention that Rails got lately I'm sure I'll never be learning Ruby / Rails. I'm into Clojure right now. Next target is Go. Sadly all these Rails exploits do have a negative eff…

When you bring up Clojure, I think it's fair to point out that, beyond even the default-unsafe reader thing brought up a couple weeks ago, the JVM itself has had several fatal security issues recently. No platform is completely without bugs.

That said, I don't really know if RoR has had more than normal or whether they're just more widely talked about. It does have a huge and vocal user-base.

Re: Rails 3.2.13 - Performance regressions and major bugs

#64

Post by steveklabnik »

ChrisInEdmonton wrote: post #55
steveklabnik wrote: post #46

Earlier quoted context omitted.

I personally read every single issue and comment filed against rails/rails. I often don't comment if it's not a part of the codebase I'm not familiar with, and it's the same with merging. Can you point me to the specific ones so I can look at them again?

Yeah, tvongaza is correct. Admittedly, it's not a _big_ issue, and perhaps I'm going about things the wrong way. If you could tell me a better way of getting this issue fixed, I'd love to hear it. The only other time I tried, it took more than two years. Luckily, it was pretty easy to monkey-patch our own code to deal with this, once it broke our live site.

Other than tenderlove and (sort of) myself, nobody is paid to work on Rails. This means that it's an entirely volunteer effort, and people's lives are busy, so sometimes, tickets take a while to merge. I try to stay on top of it actively and thing still sometimes slip through the cracks for me. It's not that you're going about it the wrong way, it's that projects with ~200 open pulls are slow to merge, sometimes. Sorry it's taking so long with this one. :/

I'll bump this up in my personal list; I should really learn AR better anyway.

Re: Rails 3.2.13 - Performance regressions and major bugs

#65

Post by ldh »

martinced wrote: post #58

I'm sure that Rails is great and powers many websites and that many devs loves it. I'm also sure that people are working hard to fix these recent security issues and perfs issues. But as a non-Rails dev I can tell you one thing: with all the attention that Rails got lately I'm sure I'll never be learning Ruby / Rails. I'm into Clojure right now. Next target is Go. Sadly all these Rails exploits do have a negative eff…

I don't write Ruby either right now, but I would suggest you not discount it as a nice language because of your perceptions of Rails.

Re: Rails 3.2.13 - Performance regressions and major bugs

#66

Post by rst »

calinet6 wrote: post #38
sergiotapia wrote: post #3

At this point I'm seriously considering dropping Rails as my framework of choice and reverting back to ASP.Net MVC. Why? 1. Security fixes are released very quickly (good thing), but more often then not they break existing code (bad thing) - and while you _can_ wait for the next patch to fix those break points, you're left wide open since everybody can see what was broken and how to exploit it. 2. I'm not nearly smar…

You're on the cutting edge of an extremely popular framework. If you want, you're welcome to use Rails 2.3 or older and you'll encounter many fewer changes. I imagine the 3.0 branch will have much the same stability once major development moves to 4.0.

FWIW, the Rails security team says they're about to drop suport for 2.3, and this time they really mean it. (They say.) The current announced security policy is that once 4.0 gets released, they'll only be doing security patches for 4.0 and 3.2; 2.3 will be left out in the cold.

It's quite possible that someone will pick up the baton, as there still are a number of production 2.3 apps out there, and porting to 3.0+ --- more a "port" than an "upgrade" --- is a real pain. But I'm not sure anyone has stepped forward yet, and until someone does, you're taking your chances.

Re: Rails 3.2.13 - Performance regressions and major bugs

#67

Post by obviouslygreen »

badgar wrote: post #57
jrochkind1 wrote: post #18

Okay, some of these problems are (unintended) direct side effects of the security fix bugs. Like I the one about scopes that effected Github -- github quoted [this commit]( https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5... ) as introducing the bug, which is the commit meant to address CVE-2013-1854. So, okay, bugs happen, even with security fixes, I can forgive bugs. But others of those performance regr…

AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs. This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.

And as is to be expected with Rails at this point, point releases break apps.

As a primarily Django guy with an interest in Rails... is this hyperbole/overstatement or is this a common perception?

Re: Rails 3.2.13 - Performance regressions and major bugs

#68

Post by hoka »

obviouslygreen wrote: post #67
badgar wrote: post #57

Earlier quoted context omitted.

AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs. This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.

And as is to be expected with Rails at this point, point releases break apps. As a primarily Django guy with an interest in Rails... is this hyperbole/overstatement or is this a common perception?

I'm also a Python dev, and my observation from several threads here (and elsewhere) is that the perception is quite common.

IANARailsDev, obviously.

Re: Rails 3.2.13 - Performance regressions and major bugs

#69

Post by yxhuvud »

FuzzyDunlop wrote: post #20

I think the only mistake made with this patch release was merging in 250+ commits, ranging from last year to the present day. Maybe that's standard for such a large project, but it feels like a hell of a lot of tweaks for a minor release. As for the rest - I think the issues in January has put Rails in the spotlight, and while scrutiny is certainly warranted, I think the extra pressure on the project over the past mo…

I think the problem is that they do too many patch releases and not enough minor releases. This could easily have been a minor.

Re: Rails 3.2.13 - Performance regressions and major bugs

#70

Post by grey-area »

obviouslygreen wrote: post #67
badgar wrote: post #57

Earlier quoted context omitted.

AFAICT Rails does point releases by just taking whatever's at head on the 3.x master branch, building a release candidate there, and iterating until nobody is reporting bugs. This isn't a security patch - a stable branch with deliberately cherrypicked fixes - it's just a plain old "point release." And as is to be expected with Rails at this point, point releases break apps.

And as is to be expected with Rails at this point, point releases break apps. As a primarily Django guy with an interest in Rails... is this hyperbole/overstatement or is this a common perception?

It's not particularly common in my experience. For example I upgraded several apps to 3.2.13 this week after tests, and haven't seen any breaking changes, and most of those apps have come up from 2.x without unexpected bugs (though I think I did have to make changes for 3.0 before going into production). YMMV, and I might have missed a subtle bug caused by this change but have checked since the github post and can't find any issues.

This bug looks like it was caused by the interaction of Github's scoping with a small change to Rails to attempt to unify the query building a little and fix a potential security issue. Where queries are merged where they apply to the same column, but (probably unintentionally) they were not merged when one was a string and one a key, which happened in some circumstances with scopes. Would love to see a slightly clearer explanation of this bug - the article doesn't provide one.

They could (and usually do) isolate the security patches in a separate release with just minimal changes - at least that would make the process more manageable, but unfortunately in this case I don't think that would have helped, as the change was directly related to a change for security and just had unintended consequences.

In fact I think from their blogpost github merged the CVE patches separately after testing rather than using the update, so having a separate security release wouldn't have helped them either, it's just an unfortunate confluence of circumstances for them due to a gap in testing (perhaps on both the Rails side and the Github side). See

https://github.com/blog/1440-today-s-email-incident

The only lesson I draw from it is that perhaps Rails could slow down their release cycle a little, issue more RC builds, and encourage large users like github to try them out extensively in development environments (hard to persuade people to do this on small point releases though). Up to now they've done a pretty good job IMHO and I've not seen many issues crop up, particularly with security releases, which are usually straightforward.

Post reply on HN