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

11–20 of 76 posts

Re: Rails 3.2.13 - Performance regressions and major bugs

#11

Post by davidw »

ryanSrich wrote: post #5

As someone who is relatively new to Rails can someone explain to me why it seems to update more than anything else I've used?

Mostly to give people on forums something to bitch about.

Serious answer: a few months ago, some serious vulnerabilities were found in Rails. This apparently had a "blood in the water" effect on security people, who started dissecting the entire thing. Predictably, more vulnerabilities have emerged and rapidly been fixed.

All in all, it means that things are improving because it's getting a ton of attention.

Re: Rails 3.2.13 - Performance regressions and major bugs

#12

Post by sergiotapia »

Axsuul wrote: post #10
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…

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.

Re: Rails 3.2.13 - Performance regressions and major bugs

#13

Post by foobar2k »

thinkbohemian wrote: post #8

Not happy? Do something about it: try release candidates, report bugs, and help triage and fix reported bugs.

I completely agree with this. We (bugsnag) are running on rails 4 beta right now to help iron out any production issues before that is released.

We didn't, however, realize that "patch" releases also have release candidates. I'd recommend following the rails blog (http://weblog.rubyonrails.org/) which announces release candidate builds too.

Re: Rails 3.2.13 - Performance regressions and major bugs

#15

Post by static_typed »

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 are now in the place I was recently -- the decision we tool was to migrate onto Python and their web ecosystem.

We haven't looked back since -- well, we have given an glance or two back since, and viewing the slow-motion car crash that is Rails today, we just feel sorry for those left behind that are discovering 'The Rails Way'.

Ironically, given DHH's comment on Rails about it being 'Omakase', I should point out that it translates as "I'll leave it to you" -- security, I'll leave it to you, software engineering, I'll leave it to you.

Food for thought indeed.

Remember -- Ruby to pose, Python for Pros.

Re: Rails 3.2.13 - Performance regressions and major bugs

#16

Post by thibaut_barrere »

foobar2k wrote: post #13
thinkbohemian wrote: post #8

Not happy? Do something about it: try release candidates, report bugs, and help triage and fix reported bugs.

I completely agree with this. We (bugsnag) are running on rails 4 beta right now to help iron out any production issues before that is released. We didn't, however, realize that "patch" releases also have release candidates. I'd recommend following the rails blog ( http://weblog.rubyonrails.org/ ) which announces release candidate builds too.

Thanks for the blog post - and I didn't realize that patch releases also had RC.

It looks like this release was quite fat, for a patch release.

I added "check rails diff" to my deploy todo list.

EDIT: I just noticed that http://weblog.rubyonrails.org/ doesn't have a way to subscribe by email. I signed-up by email with this site instead http://blogtrottr.com, in case it helps other here.

Re: Rails 3.2.13 - Performance regressions and major bugs

#17

Post by josephlord »

nifoc wrote: post #9
scottshea wrote: post #2

You know when you're already having performance issues on Heroku having a performance regression is not fun.

How is this > […] handing that task to Sprockets instead of resolving internally […] even remotely related to performance issues because of random routing? You're mixing two issues that have nothing in common.

1) Grandparent has performance problems on Heroku.

2) The Rails release has performance regressions (i.e. in at least some scenarios is slower).

In situation (1) you don't want to add further slowdown so (2) is a bad thing.

Grandparent doesn't even blame his Heroku performance problems on the routing issue (although it is a plausible guess). Actually effect of the routing problem can be significantly worsened if even a subset of requests are slowed down.

Re: Rails 3.2.13 - Performance regressions and major bugs

#18

Post by jrochkind1 »

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 regressions... " handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues."

This doesn't sound like the unanticipated side effect of a security fix. This _sounds_ like an independent change they threw into the same patch release with four (four!) security patches.

Why is Rails putting security fixes and other non-security-related enhancements together in the same patch, so you can't get the security fixes without also getting the possibly buggy new features/refactors? Does Rails actually do this by policy? Was it a mistake?

Bugs happen, including bugs in security fixes, sure. But it's BECAUSE bugs will happen that you don't throw unrelated new features or refactors into the same patch release as a security patch, so the only way to get the security patch is to risk MORE problems from the other stuff too! Come on!

Re: Rails 3.2.13 - Performance regressions and major bugs

#19

Post by thinkbohemian »

foobar2k wrote: post #13
thinkbohemian wrote: post #8

Not happy? Do something about it: try release candidates, report bugs, and help triage and fix reported bugs.

I completely agree with this. We (bugsnag) are running on rails 4 beta right now to help iron out any production issues before that is released. We didn't, however, realize that "patch" releases also have release candidates. I'd recommend following the rails blog ( http://weblog.rubyonrails.org/ ) which announces release candidate builds too.

You can also subscribe to the rails-core mailing list, all betas, RC and full releases get announced there.

Re: Rails 3.2.13 - Performance regressions and major bugs

#20

Post by FuzzyDunlop »

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 months to clear this stuff up has had its consequences.

Post reply on HN