Live data from Hacker News

Rails 3.2.13 - Performance regressions and major bugs

blog.bugsnag.com

71–76 of 76 posts

Re: Rails 3.2.13 - Performance regressions and major bugs

#71
post #59

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.

The rails team already does this. Here's an example patch for one change:

https://groups.google.com/forum/#!msg/ruby-security-ann/o0Ds...

Unfortunately that wouldn't have avoided this issue, as the problem was actually with the small security patch.

Re: Rails 3.2.13 - Performance regressions and major bugs

#72
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?

From my own anecdotal experience it is true. The ruby gem responsible for most point release breakages affecting me is probably activerecord.

Re: Rails 3.2.13 - Performance regressions and major bugs

#73
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 was certainly the case on the 2.3 "stable" branch two or three years ago: http://david.rothlis.net/rails/experience_report/#stable_bra...

Re: Rails 3.2.13 - Performance regressions and major bugs

#74

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 should seriously consider running mono>=2.10 with asp.net mvc. It completely fixes your rails security issues, while still letting you use ruby as your main languages.

Also you gain a _lot_ in security by obscurity and hipster points. I don't know about stability, haven't tried this myself.

Check out the mono project for details: http://www.mono-project.com/Mono_Project_Roadmap

Re: Rails 3.2.13 - Performance regressions and major bugs

#75

I disagree with the final statement of this, that a "security only" release would have somehow helped the situation. I feel like part of the problem is that things are being merged into 3-2-stable and nobody is using them because they're never put into a release. 3.2.11 and 3.2.12 were both security-only releases, and so fixes and patches that were not security-related have just been piling up for the longest time. S…

Actually 3.2.12 also added some sort of silly (and broken) patch related to quoting numeric values in ActiveRecord. The primary thing I want out of 3.2.13 is reverting this.

To your more general point, while I don't disagree with your diagnosis of things piling up in stable, I'm also not a big fan of your proposed solution. It looks to me like 3-2-stable is getting filled with a lot of stuff that just should not there; increasing the release frequency is not going to solve this problem.

Re: Rails 3.2.13 - Performance regressions and major bugs

#76
post #74

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 should seriously consider running mono>=2.10 with asp.net mvc. It completely fixes your rails security issues, while still letting you use ruby as your main languages. Also you gain a _lot_ in security by obscurity and hipster points. I don't know about stability, haven't tried this myself. Check out the mono project for details: http://www.mono-project.com/Mono_Project_Roadmap

I've not heard of anyone using IronRuby in earnest, and it doesn't seem to have been updated in a couple of years. Is it a realistic option?
Post reply on HN