Rails premieres on GitHub

Posted by David April 11, 2008 @ 01:45 PM

GitHub has now officially launched and Rails is right there at the premiere. The Rails repository now lives at rails/rails and you can check it out with:

git clone git://github.com/rails/rails.git

If you don’t have git, or don’t enjoy running it on your platform, you need not fear. We’ve set up an automated task to produce a zip file of Rails Edge that’ll be kept up to date all the time: http://dev.rubyonrails.org/archives/rails_edge.zip. This is also what we’ve made the new rake rails:freeze:edge use.

This also means that development on the Subversion repository has stopped and will no longer be kept up to date. We’ll keep the Subversion repository around for some time for people to transition off svn:externals, though. But if you want the latest edge, you’ll have to use either git or the new zip files.

We’ll also soon go live with our new ticket management system, which will be running on a new version of Lighthouse. When that happens, the Trac installation will follow the Subversion repository into legacy. We’ll still keep it around so we can work through all the patches and tickets that are there, but everything new will happen on the Lighthouse setup.

We hope you’ll enjoy this upgrade to the Rails collaboration infrastructure. We’re really looking forward to the onslaught of marvelous patches that the Git lords have promised us will flow from the mountain now.

Posted in Edge  | 41 comments

Rails is moving from SVN to Git

Posted by David April 02, 2008 @ 09:39 PM

We’ve been preparing for Rails to move the official source repository from Subversion to Git for some time now and it seems that it’ll happen over the next week or so. The premiere will happen alongside the official launch of Github.

The move will also mean that we’re going to be switching ticket tracking to Lighthouse. So now both our repository and ticket tracking will be powered by Rails applications, which is a nice bonus treat.

When the move happens, we’ll freeze the existing Subversion repository and the Trac installation. Both will live on for a long time to come, but will be entirely deprecated. This means that your existing svn:externals will not break, but if you want the latest edge, you’ll have to get it from the new git repository.

So now is a great time to learn more about Git in anticipation of this move. I recommend starting with the Git for SVN’ers crash course.

Posted in Edge  | 95 comments

Adapter gems available

Posted by David October 01, 2007 @ 02:31 PM

The extracted adapter gems are now available for install from the gems.rubyonrails.org server. Say you want the Oracle adapter installed, you just do gem install activerecord-oracle-adapter. All the extracted gems are:

• activerecord-firebird-adapter
• activerecord-frontbase-adapter
• activerecord-openbase-adapter
• activerecord-oracle-adapter
• activerecord-sqlserver-adapter
• activerecord-sybase-adapter

The mysql, postgresql, and sqlite adapters are still included in Rails core.

These will be released to the standard Ruby repository alongside Rails 2.0 when that reaches final.

Posted in Edge  | 13 comments

How to get a patch into Rails

Posted by David September 15, 2007 @ 09:46 PM

For a while, the patch queue was getting badly out of hand. The flood of new entries was simply too great to be reasonably managed by a small group of people. Too much got stuff got stale and their creators got disillusioned, understandably so. But for a while now, we’ve been running with a new policy on patches, which seems to be working a lot better for those who’ve been following it.

But I’m sensing that a fair number of people are not aware of those changes in policy, so I thought best to bring them up again here.

Step 1: Raise the barriers of quality

Part of the reason that the original patch queue got out of hand was due to the large number of patches coming in that lacked essential qualities of a good patch. They were either missing a good rationale (why am I doing this? what’s the benefits?), good test cases, or didn’t update the relevant documentation. To apply such a patch meant that this work had to be shouldered by someone else, usually the guy who wanted to apply the patch.

Now the barriers of quality are more apparent. Your patch will simply not be considered for inclusion before it has all those elements. It’ll live with the “unverified” keyword until you or someone else that cares especially deeply about the patch (like someone else having the same problem) gets the quality up to par. Then the patch moves on to step 2.

Step 2: Get the community engaged to review your patch

The last step before your patch is ready to be put in the queue for inclusion is to get community support round up. We now require that three different people must review your patch, apply it, run the tests, read your documentation, and like what it does and how it’s implemented. When they do, they’ll make a comment on the ticket with a “+1”.

Get three such +1s and you can tag your patch with the “verified” keyword. That’ll make the patch appear in Report #12: Verified Patches, which is a bell telling the core team that you patch is baked and ready to be included (barring a final review).

The core team is trying to keep report #12 empty at all times. There shouldn’t be a big lag time between getting to “verified” and getting a final review of your patch, which will either send it back to unverified (because the implementation is deemed in need of work or because there’s some fundemental disagreement over whether or how this patch goes about its business) or it’ll be applied and available in edge.

So if you have a patch that you still care about sitting in the queue, dust it off, and put it through these two simple steps and you’ll be back on the road to glory. There are still no guarantees that your patch will receive immediate attention, but so far we’ve managed to keep report #12 moving very nicely. It’s all empty as of today!

The front page of http://dev.rubyonrails.org has been updated to reflect this policy.

Posted in Edge  | 15 comments

Plugin loading internals have changed, for the better!

Posted by marcel March 02, 2007 @ 09:01 AM

Until now, the task of locating and loading plugins into your app was handled by a handful of private methods on the Rails::Initializer. These methods were fairly large, coarse grained, and as a result hard to hook into without resorting to fragile cut and paste if you wanted to customize how your plugins are loaded.

New in Edge Rails, changeset 6277 replaces this smattering of methods with two new internal classes, Rails::Plugin::Locater and Rails::Plugin::Loader. If you need to hook into how plugins are loaded, you can define a subclass of Rails::Plugin::Loader, then register your custom class to be the class that handles plugin loading using the new plugin_loader configuration option in your config/environement.rb:

  Rails::Initializer.run do |config|
    # Config settings...
    config.plugin_loader = PluginLoaderWithDependencies
  end

This should make extensions on top of the plugin system, such as the Plugems approach developed by the team over at Revolution Health, far easier to implement and maintain.

To those monkey patching the plugin loading subsystem in Rails, this introduces substantial changes to the way that plugins are located and loaded. In the short term this might mean that your customizations to the internals will very likely break, but the good news is that in the long term the new implementation will be far easier to customize.

For those adventurous early adopters living on the Rails Edge, please give your apps a test run to ensure these changes don’t break anything for you. As always, bug reports and patches are welcome: http://dev.rubyonrails.org/.

Posted in Edge  | 18 comments