Wait, what was that last bit?
So some of you may have seen the news about Gemcutter.org changing its name to RubyGems.org and becoming the new default gem repository for the Ruby community. I’m not completely clear yet on all the pros and cons of this move, but I do have to admit that the new site is pretty to look at. As a maintainer, I like the idea of being able to just type “gem push fxruby” (or whatever the command syntax is) and being done with it. So I think this will probably turn out to be a good thing.
Buried a few paragraphs down in the news, however, is this tidbit:
So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away.
In the comments, I asked for clarification on exactly what RubyForge services will be going away, and Tom Copeland’s reply seems to indicate (to me) that the answer is “everything”:
… We’re putting together a schedule for standing down (or making read-only) various bits of RubyForge. The thing is that now there are much better options for hosting code/forums/lists/files/etc, so that stuff is going to be retired. I think back in 2003 it made sense for the Ruby community to have a dedicated site for hosting that stuff. Now I don’t think it does… I think GitHub/Google Code/SourceForge can all do a better job at that, and Ruby Central doesn’t have to expend resources/time/money supporting functionality that others are doing better.
This is troubling to me since several FXRuby-related services (such as the web page hosting, bug tracker, and mailing lists) are handled by RubyForge, and have been for a long time now. For me, it’s not merely a question of, say, finding a new place to host the mailing lists. It’s also making a decision about what to do with the archives, and dealing with all of the non-readers who will go out their way to try to subscribe to the old lists even when they’re clearly marked as inactive and then send e-mails to me to ask why that’s so. But I know that Tom and company are sensitive to these concerns, and we’ll figure out a way to make the transition work as painlessly as possible, so I’m going to try not to be a grumpy old man about it.
So in the meantime, I’m beginning to consider what my post-RubyForge options are. Setting up a dedicated Redmine installation, as Jim Weirich has done for his projects, is an attractive option as it provides one-stop shopping (and I’ve had some experience with setting up Redmine for other projects already). Another option is to go with different sites targeted at the different services, like entp’s Lighthouse for bug tracking, maybe Google Groups for the mailing list hosting, and maybe piggybacking the static web site content off of my personal web site somehow (ugh). What about you, dear reader? If you’re hosting one of the 8,500 projects at RubyForge, what plans are you contemplating for RubyForge’s looming retirement?
Lyle,
How about GitHub? They’ve got static page serving through GitHub Pages, you can post downloads as well. Issues might be a little light weight for most projects but it does the job.
October 26th, 2009 at 5:11 pmGitHub pages are definitely a possibility; the main problem is that I’d like for fxruby.org to point to that site without having to become a paying member at GitHub (RubyForge provided this for free). And I had completely overlooked GitHub’s issues feature, so I need to see if that would do the job without having to look elsewhere. Thanks for the leads!
October 26th, 2009 at 7:38 pmHello Lyle,
I’m one of these folks with concerns about this, as I’ve expressed in the same posts at Gemcutter and the recent email sent by Richard Kilmer to Ruby-core.
A few months ago I decided to move RubyInstaller downloads from my personal website (where we host rubyinstaller.org right now) since was hitting really hard in the bandwidth of my small account.
Before that, tried get these files uploaded to GitHub cloud (download section) without luck.
This also will be a problem for projects like MySQL/Ruby, which doesn’t perform gem releases (just tar.gz) and is the base for the work my repository at GitHub does to package it.
That subtle change in RubyForge mean these .tar.gz, installers or other filetypes will need to find places across the web to be hosted, or relocate to SourceForge, which I find extremely more confusing that RubyForge.
So: you’re not grumpy, sometimes changes are good, but I’m still having a hard time see those things “fit” in the social or community features that will be added to Gemcutter/Rubygems.org
October 26th, 2009 at 9:57 pmIf any of the committers on the fxruby repo are paying GitHub members you can use a CNAME.
October 27th, 2009 at 12:36 amCollaborators I should have said.
October 27th, 2009 at 12:36 am@Luis: Right. For my project, all of the artifacts can be gems so that particular aspect is not a roadblock for me, but I know that a lot of projects (such as RubyInstaller) are not or cannot be gem-ified.
@PJ: Thanks for that additional info. I will put the word out to the FXRuby mailing list to see if anyone is a paying GitHub member.
October 27th, 2009 at 7:52 amI think moving stuffs to sourceforge is the best bet.
October 27th, 2009 at 1:33 pmHi Lyle. Regarding my Redmine installation, I should mention that I’m in the process of switching over to Pivotal Tracker for ticketing, mainly to get out of the hassle of maintaining Redmine on my own server.
October 27th, 2009 at 1:36 pm