In the tradition of actions vs. words, I present to you:
RubyScience - A Collection of Ruby Science Libraries and Projects
http://github.com/jballanc/RubyScience
I like the git idea a lot. Last year I ported a Ruby science library to
Ruby 1.9, made it into a gem, sent the changes to the maintainer and nothing
became of it. Not the maintainers fault. He was just too busy. If it's
distributed that's just not a problem.
This is a neat idea; basically to wrestle unmaintained or
not-quickly-updated libraries into the useable limelight. This alone
could be a fantastic accomplishment worthy of the project.
The whole point of Open Source is just this. GitHub just makes the practice a bit easier to match up with the theory. If I get hit by a bus or loose interest, I fully expect someone to fork this project and keep it up to date (if there's still interest, of course).
But I'm not clear on logistics. Is the idea to import other peoples
code into github if they don't already exist there? That seems like a
lot of work, not just initially but also to keep up with releases.
Right now I'm favoring GitHub repositories (for example, the base repo for Chipmunk is on Google Code; I've included the GitHub fork setup for Debian maintenance). As I first mentioned, the idea I had was a GitHub "group", so my primary interest is in GitHub repos. Also, since everything is just set up as a git submodule, none of the actual code resides in the repo. This, I think, best reflects the point of the project. That is, if you want to modify the code for one of the libraries, please fork and modify the original and not what you find in RubyScience.
Now, that said, I realize that not every project lives on GitHub. There are three solutions to handle this:
1. Ask the project to setup a GitHub mirror. Public repos are free, and some simple post-commit hooks should make maintenance relatively painless. Of course, not every project will be receptive to this scenario so:
2. We could setup GitHub repos for projects that we want to carry across. If we go down this route, I'd ask for volunteers to handle the synchronization. I'd prefer this to:
3. We could pull code from other repos directly into RubyScience. I have a script that automates the task of updating git, git-svn, svn, and cvs repos (adding hg and bzr support shouldn't be too difficult). I'd like to stay away from this, though, since I really want the projects included in RubyScience to live in their own git repos.
The other problem is what would constitute a pseudo-official
"release"? Whose fork or repo would incorporate other efforts or
resolve which of two different forks of, say, ruby-gsl to include?
I'd welcome discussion on this, but for the sake of ruby-talk I'd invite those interested to sciruby-talk (to which I'll be cc'ing this message). The easy answer, of course, is that if you don't like my decisions you're free to maintain your own fork ;-). The better answer is that when it comes time to put together a RubyScience/sciruby umbrella gem (say once every quarter or so) we'd likely want to contact each repo maintainer for guidance on what to include.
···
On May 18, 2009, at 5:42 PM, Cameron McBride wrote:
On Mon, May 18, 2009 at 15:49, Juan Zanos <juan_zanos@talkhouse.com> > wrote:
On May 18, 2009, at 3:27 PM, Joshua Ballanco wrote:
