On May 18, 2009, at 5:42 PM, Cameron McBride wrote:
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:
-
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:
-
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:
-
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.
