Congrats to you guys for the well deserved recognition. And thanks to the RubyForge team for years of often thankless work, and for having the maturity and lack of ego necessary to keep the focus on what's best for the community.
wastedbrains
· 1 month ago
Congrats a big step forward for a better gems solution.
luigimontanez
· 1 month ago
Great news!
What will happen to the websites at projectname.rubyforge.org? That's the public project page for many gems now. Will there be redirects set up?
tcopeland
· 1 month ago
Moving my reply from below into the proper place, doh:
"Those virtual hosts will not be taken down right away... I suspect we'll put them in read-only mode in a few weeks, though. But we'll do tarballs of that and other stuff that's currently on RubyForge, and generally make it easy for folks to migrate away."
undees
· 1 month ago
A lot of (gemname).rubyforge.org sites are just RDoc pages; you may well be able to just redirect them to whatever gemcutter is going to do for gem documentation.
James
· 1 month ago
This is excellent news, congrats! :)
tcopeland
· 1 month ago
Those virtual hosts will not be taken down right away... I suspect we'll put them in read-only mode in a few weeks, though. But we'll do tarballs of that and other stuff that's currently on RubyForge, and generally make it easy for folks to migrate away.
drawohara
· 1 month ago
keep me in the loop tom, if you guys need help porting rubyforge.rb to provide a compatibility layer i'll volunteer to do that.
tcopeland
· 1 month ago
@drawohara I'm not sure if we even still need the rubyforge library - I mean, all we really need with gemcutter is "gem push blah-x.x.gem", right? No news postings, no packages, no releases, etc... just a gem push.
drawohara
· 1 month ago
i'm thinking your spot on. still might be a few weeks or months when backwards compat for publishing should/could be supported via the rubyforge gem - a deprecation period - to avoid creating pain for people with lots of scripts and rakefiles lying around that shell out to the rubyforge.rb gem - 99.9% of which will be doing simple pushes.
if it's NOT needed that that's even better, but i'll lend a hand if it is.
tcopeland
· 1 month ago
Yeah, maybe we can just stub out add_release, add_package, post_news... and replace add_file with a call to gemcutter? Hm, we'll need to redo "rubyforge config" to do something different. You're right though, would be nice if that stuff could continue to work. Well, at least we'll be deleting code rather than writing it :-)
drawohara
· 1 month ago
i prefer to use the word 'improve' rather than 'delete' ;-)
100% agreed on the stubs - in fact they could even try gemcutter behavior now and, iff that fails, fallback to old behavior. something like that...
tcopeland
· 1 month ago
"improve", quite right!
The only thing is that the old behavior won't be valid any more - I mean, there's no "package" concept in gemcutter, and there won't be a rubyforge-based gem index. So we'll need to adjust various client code accordingly.
That would be awesome if gems.rubyforge.org points to rubygems.org. This way older versions of RubyGems will automatically update without doing anything.
qrush
· 1 month ago
Ryan, that's the exact plan. :)
Juvenn Woo
· 1 month ago
Thanks for your excellent work.
Just realized qrush == Nick Quaranto. GitHub guys are really super awesome, aha?
Craig Jolicoeur
· 1 month ago
Wow, big news. Good news though.
Bob Martens
· 1 month ago
Awesome news and congrats to everyone!
Botanicus
· 1 month ago
Well done mate!
Lyle Johnson
· 1 month ago
First things first: This is good news, and I'm glad that the gem hosting situation is improving. I am however concerned about what this change means for RubyForge, especially when I see statements here like "the parts [of RubyForge] that other sites can do better will be pruned away", and "(unidentified) RubyForge features will be put into read-only mode." I've bookmarked the transition Wiki page that you linked to and will watch it for updates, but I hope you or Tom can clarify what's going to happen on the RubyForge side.
tcopeland
· 1 month ago
@lyle yup, 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.
luislavena
· 1 month ago
@tcopeland I'm a bit worried for packages that are _not_ gems.
One example of that is RubyInstaller. We use RubyForge to distribute installers and concentrate Bug tracking, patch queue and releases there.
The read-only and the transition seems that is going to hit us pretty hard. Please let me know if that is true or not.
Thank you.
tcopeland
· 1 month ago
That's true, some projects will have more to move than others. The same applies to the "ruby" project on RubyForge where I've been posted releases of Ruby for the past few years. Ditto the rubygems project.
Here's the thing, though - other places are going to do that stuff better. For example, how do the RubyForge file mirrors work? Well, there's an rsync process that gets run by a cronjob that transfers the files to an rsync mirror and then outwards to other mirrors. When someone downloads a file, the RubyForge PHP app randomly picks a mirror and redirects to it. Sites like SourceForge have a much quicker mirroring system, and they also do mirror choosing so that folks can get a mirror that's close to them. I'd be willing to bet they also have a better backup system than RubyForge does. And finally, I bet they're more secure, too, so you don't really need to worry about that end of things.
I know this weighs hard on projects like rubyinstaller and others that primarily provide files. But I think it's going to be a net win.
luislavena
· 1 month ago
Hmn, that means file releases will not be possible on RubyForge anymore.
And Gemcutter purpose is distributing gems.
This means something like RubyFiles will need to be created and implemented so people will be able to release packages?
That means another login credentials, register, account activation, password, etc.
Divide and conquer start to sound familiar...
tcopeland
· 1 month ago
I think people will move files to other hosting places - e.g., to SourceForge or to Github. Those sites have excellent facilities for hosting/mirroring/backing up/downloading files... but the Ruby-specific stuff - gems - will stay on a Ruby Central-sponsored site.
tcopeland
· 1 month ago
By the way, let's definitely discuss how to ease the transition. For example, we can tar up all the releases if that would help... and maybe add stuff to the API to help export open tracker items... I'd be happy to work on anything like that.
Name
· 1 month ago
retiring rubyforge lists too? that's going to be a huge transition for a lot of users.
tcopeland
· 1 month ago
Yup, but I think folks will get better service from a Google group. The RubyForge Mailman install works, but you can't search the lists and there are occasionally delays in getting messages through. I can appreciate that there are going to be some pain points, but overall I think the Ruby community is going to be in a better situation with only the Ruby-specific parts of RubyForge folded into rubygems.org.
Eric Wong
· 1 month ago
I've seen a lot less spam with Rubyforge Mailman than Google Groups. I don't think it's possible to easily download past archives without crawling Google Groups, either. Anyways librelist.com provides an alternative to Google Groups if downloadable archives is a requirement. Maybe other options are available, too...
Please just make sure you give us ample warning if you disable anything, thanks :)
tcopeland
· 1 month ago
Ah cool, well, I'm glad that greylisting thing was doing more than just annoy people :-) Yeah, there are lots of options out there for list/forum hosting... there'll be some stuff to move around, but we'll try to make it as painless as possible.
rubiii
· 1 month ago
Great news!
mdub
· 1 month ago
Awesome! Thanks to Nick for giving us the next generation of gem hosting, and to Tom both for setting the standard, and for helping to make the transition so smooth.
Ryan Sobol
· 1 month ago
A *BIG* thank you Tom and Nick for joining forces and having the strength to put egos aside. It's clear you both just want to best possible ruby gems hosting solution for our rapidly growing community. If there's anything I can do to help, don't hesitate to drop me a line.
Thomas Leitner
· 1 month ago
I think that the facilities provided by Rubyforge are great: by registering your project, you get access to all the basic services needed by a Ruby-centric project:
* Website hosting (static is fine for most projects I think) * File hosting * Bug tracking * Mailing lists
Although I really like the idea of having a central gem repository (no more github gems), I will definitely miss the above features of Rubyforge since I constantly use all of them.
Another thing that should not be forgotten: It was relatively easy in the last years by registering two feeds (RAA and rubyforge) to get information about project updates and new ruby projects. When there is no Rubyforge anymore (the number one site where new Ruby projects have been hosted), registering new ruby projects on RAA gets even more important!
Many thanks to Tom Copeland for the superb and quick support!!!
Skade
· 1 month ago
November 19? Isn't that a bit quick for a site so central to Ruby?
All Comments
What will happen to the websites at projectname.rubyforge.org? That's the public project page for many gems now. Will there be redirects set up?
"Those virtual hosts will not be taken down right away... I suspect we'll put them in read-only mode in a few weeks, though. But we'll do tarballs of that and other stuff that's currently on RubyForge, and generally make it easy for folks to migrate away."
if it's NOT needed that that's even better, but i'll lend a hand if it is.
100% agreed on the stubs - in fact they could even try gemcutter behavior now and, iff that fails, fallback to old behavior. something like that...
The only thing is that the old behavior won't be valid any more - I mean, there's no "package" concept in gemcutter, and there won't be a rubyforge-based gem index. So we'll need to adjust various client code accordingly.
Q: Will http://gemcutter.org stay alive?
Just realized qrush == Nick Quaranto. GitHub guys are really super awesome, aha?
One example of that is RubyInstaller. We use RubyForge to distribute installers and concentrate Bug tracking, patch queue and releases there.
The read-only and the transition seems that is going to hit us pretty hard. Please let me know if that is true or not.
Thank you.
Here's the thing, though - other places are going to do that stuff better. For example, how do the RubyForge file mirrors work? Well, there's an rsync process that gets run by a cronjob that transfers the files to an rsync mirror and then outwards to other mirrors. When someone downloads a file, the RubyForge PHP app randomly picks a mirror and redirects to it. Sites like SourceForge have a much quicker mirroring system, and they also do mirror choosing so that folks can get a mirror that's close to them. I'd be willing to bet they also have a better backup system than RubyForge does. And finally, I bet they're more secure, too, so you don't really need to worry about that end of things.
I know this weighs hard on projects like rubyinstaller and others that primarily provide files. But I think it's going to be a net win.
And Gemcutter purpose is distributing gems.
This means something like RubyFiles will need to be created and implemented so people will be able to release packages?
That means another login credentials, register, account activation, password, etc.
Divide and conquer start to sound familiar...
think it's possible to easily download past archives without crawling Google
Groups, either. Anyways librelist.com provides an alternative to Google
Groups if downloadable archives is a requirement. Maybe other options are
available, too...
Please just make sure you give us ample warning if you disable anything, thanks :)
* Website hosting (static is fine for most projects I think)
* File hosting
* Bug tracking
* Mailing lists
Although I really like the idea of having a central gem repository (no more github gems), I will definitely miss the above features of Rubyforge since I constantly use all of them.
Another thing that should not be forgotten: It was relatively easy in the last years by registering two feeds (RAA and rubyforge) to get information about project updates and new ruby projects. When there is no Rubyforge anymore (the number one site where new Ruby projects have been hosted), registering new ruby projects on RAA gets even more important!
Many thanks to Tom Copeland for the superb and quick support!!!