4 ms·
I respect what Ryan's trying to do here, and understand the frustration that is almost unavoidable when working on a community-driven open source project with a
by cscotta 17y ago
I respect what Ryan's trying to do here, and understand the frustration that is almost unavoidable when working on a community-driven open source project with a large number of users.
But at the same time, I'm frustrated. I've found bugs, worked around them, written up an incredibly detailed description of one. I wrote a patch, wrote tests for the patch, and mentioned that I was a first-time contributor and wanted to do it right. After a few positive comments, a member of Rails core came along, made a dismissive comment, and left.
If you're going to write blog posts calling community members "useless, pathetic bastards", you darn well better make sure that the community is one that welcomes patches, encourages positive discussion, and if the patches or contributions are inappropriate/applied at the wrong level of abstraction - work to get it there.
Otherwise, you'll end up with a community of users that maintain their own local patches, forking the core or components of it because the mental overhead of sponsoring a patch and pushing it through takes weeks, while just Getting it Done is a couple lines of code and push to your repo. Which is (sadly), kind of where I'm at.
I love Rails. I like many of the principles it rests on, and I love the flexibility it offers. I've learned at least half of what I know about software development and engineering while programming Ruby. But when it comes to dropping writing elegant code so that I can spend hours hammering through endless gut-wrenching arguments on a Lighthouse ticket - count me out.
- fizx 17y agoData point: I submitted a simple patch for Rails 3 that got resolved in about 2-3 days. On the other hand, I have good friends who have experienced the same issues you describe.
- nikz 17y agoCould you post a link to the patch in question?
- ryanbigg 17y agoI agree. If you want eyes on your patch I have two of them right here that I'm willing to send your way. Name and shame tickets that have been left open and the reasons why.
- cscotta 17y agoSure - it was awhile back and water under the bridge by now, but the original ticket was here: https://rails.lighthouseapp.com/projects/8994/tickets/2628-ruby-19-and-activesupport#ticket-2628-4 https://rails.lighthouseapp.com/projects/8994/tickets/2628-r... The bug was a Ruby 1.9-specific issue that another user had stumbled on which I hit as well. Unicode support in the 1.9x series is great, but brought some trouble along with it. The problem in this case was that ETag generation in ActionController tested the response data using a method that threw an exception if it hit a string with an encoding issue. As such, the request would die after being processed, but before being returned to the user. Because it occurs after calling render in ActionController::Response, the exception was unrescuable. (Ed: No 500 error page, no rescue_action_in_public, or any indication of an exception - just an HTTP response with an empty body). It was a sticky situation. Read my longer comment if you're interested in a full explanation. Anyway, I don't mean to re-open the discussion now. I eventually resolved the issue by applying this patch locally, then moving to a new encoding-aware MySQL adapter. Life's good.