From: Juan Zanos Date: 2009-05-19T22:26:06+09:00 Subject: 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 > 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. > > 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. > > 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? > > Maybe the github community has acceptable solutions for these > situations. I haven't followed the social aspect of github at all. > > Cameron The import isn't much work in most cases. There are different solutions for different situations. Creating a git repo is trivial. If something is already in git you can just clone it. If it's in Subversion you can 'clone' it with git-svn. If it's in Bazaar you can use bzr-svn, etc. You can continue to pull or push changes from the original repository if necessary. People are sometimes conservative about keeping some of the old repos around, but it might be better to nuke them rather than spend the effort maintaining them. I think the "officialness" part is overrated in the distributed world. Would you rather have an "official" library that needs a lot of work or an unofficial one that someone has kindly updated so it's closer to what you need? That said, an "official release" is still faithfully reflected in every repo that has fetched from any repo that contains the "official release". Repos have tags and branches and these are immutable. So it doesn't matter from which repo you checkout say "totally official release 3.2". As for merging, it doesn't really matter so much who does a merge so long as you like the result. If you don't like it you can fix it or decide that whoever did it is going down an evolutionary dead end and ignore them. Github is great. But a lot of the social networking stuff is built right into git. You can quickly see the entire history of every repo you've ever fetched from without using any 3rd party tools.