Long version:
I hit an error with Rails 2.3 on Ruby 1.9.1, debugged it, and fixed it locally. Now, I'd like to open a bug report and submit a patch, but I'm having a hard time figuring out how.
I'm watching a RailsCast, but every little step is taking hours. The lighthouse site was down (but is back up now), I didn't have (and had never used) git, I just spent an hour getting mysql [1] installed (since the RailsCast claims it's required by rails self-test suite), and now rails test is failing with a bug that somebody else apparently reported yesterday against Netbeans (which I'm not using). [2]
1. Btw, why doesn't mysql on OS X read ~/.inputrc? GNU readline is installed.
There are a few technical considerations to look at, which I've added
to #2130.
However, on a procedural note, Git is pretty much required to submit
patches.
There are a few technical considerations to look at, which I've added
to #2130.
However, on a procedural note, Git is pretty much required to submit
patches.
Understood. That's my next step. I've been getting bitten by "technical considerations" on that front, too, but I'm hoping to have it working later today.
What's the right way to test this fix? I don't see any tests for class RailsEnvironment.
I'd argue that since this is essentially just a Ruby 1.9 compatibility
thing, that it shouldn't really need testing. Especially if you adopt
the approach used earlier in the same file.
I'd argue that since this is essentially just a Ruby 1.9 compatibility
thing, that it shouldn't really need testing.
Agreed, although a smoke test on 1.8 would do my heart good. How does that sort of thing usually work? Are there volunteer alpha testers, or nightly regression tests, running in different environments, with different versions of Ruby?
Especially if you adopt
the approach used earlier in the same file.
I'm not sure what you mean here. The relevant class, RailsEnvironment, is the first in the file (plugin.rb), and the file does not contain any mention of testing. There is a PluginTest class in plugin_test.rb, but it doesn't directly test RailsEnvironment.
The RailsEnvironment class depends inherently on the caller's environment, so this is kind of a special case. For the failure to happen, there has to be a .svn directory in "#{root}/vendor/plugins", and backtick calls to svn must work. If the user hasn't got svn installed, should we mock out a stub just for this test? I see that PluginTest already uses some stubbing tools, but I'm not familiar with them.
I'm guessing that for a Ruby newbie like myself, adding the test is probably about a day's effort, and the code may not be as, uh, aesthetically pleasing as one would like. I'll give it a shot, anyway.