Re: [ANN] Introducing RubyScience on GitHub!

On May 18, 2009, at 5:42 PM, Cameron McBride wrote:

> On Mon, May 18, 2009 at 15:49, Juan Zanos <[e-mail]>  
> wrote:
>> On May 18, 2009, at 3:27 PM, Joshua Ballanco wrote:
>>> 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.