Let's assume IronPython moves to github. There would be two options:
1) We could just rename the current IronRuby repo to "DynamicLanguages" repo and IronPython can use it as it is (more or less). 2) It might be possible to split the repo to 3 parts - IronRuby specific, IronPython specific, and DLR, make a submodule for each and combine those submodules into "DynamicLanguages" repo. So what's exactly the effective difference among the repo built this way and 1)? AFAICT it's only that super-module doesn't track the head of the sub-module automatically. You need to manually update it to the latest version. How does that help us? If we have a (single) CI server that makes sure that both IronPython's and IronRuby's heads are passing all tests, what is the advantage of not using the latest source code of each other? Or am I missing something (maybe I misunderstand what git submodule can do)? PS: All this is orthogonal to minor refactoring of the current directory structure that is a no-brainer and I already mentioned them (like removing LCA_RESTRICTED). Tomas From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Mike Moore Sent: Monday, October 25, 2010 10:28 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Contributing? On Mon, Oct 25, 2010 at 4:22 AM, Andrius Bentkus <andrius.bent...@rwth-aachen.de<mailto:andrius.bent...@rwth-aachen.de>> wrote: On Sun, Oct 24, 2010 at 1:57 AM, Michael Letterle <michael.lette...@gmail.com<mailto:michael.lette...@gmail.com>> wrote: FWIW having separate IronRuby, IronPython, and Common repos that are sub moduled(is that a word?) would make sense, that way changes that are done in Common by both people working on Ruby and Python are easily shared.. the current configuration feels.. fragile. There is a major problem: different vcs tools. I guess the IronPython project will stay with TFS/SVN while IronRuby will use git(hub). Having common submodule repos managed by different VCS would be a world of pain. There is no way of dividing the project into submodules if IronPython doesn't move to github/git. Maybe some git-svn magic would help and mirror versions on github of the svn repositories would be needed. I don't think this would be too difficult to work around. There is already some process that replicates changes from the IronPython's CodePlex repo to IronRuby's GitHub repo. If the current monolithic project structure were broken up into submoldules, you could have just IronPython's CodePlex being replicated to an IronPython git repo. I think that another major problem the IronRuby project has are the 4 sites with IronRuby content. There are like 4 sites now on github, rubyforge, ironruby.net<http://ironruby.net> and the codeplex with different content on ironruby. This is madness, IronPython as only 2 sites, ironpython.net<http://ironpython.net> and codeplex and that makes sence. When I looked into the project I was just confused, because I couldn't find any information and the little bits of Information were scattered and outdated. And this is a real dilemma, because you just can't move away from any of these sites: you have to stay at codeplex at because it is an Iron project, you have to stay at rubyforge because it is ruby afterall, you can't move from github, because all the ruby kids use git, so there is only ironruby.net<http://ironruby.net> left, but you can't get rid of that either, it's after all the ironruby domain. The purposes of the sites need to be trimmed down: use codeplex and rubyforge only for binary distribution, github for versioning, issue tracking and wiki and ironruby.net<http://ironruby.net> as a presentation site just like ironpython.net<http://ironpython.net> is, cut the documentation out of it and stuff it in the github wiki, redudancy is hard to version. I don't think that keeping the issue tracking system on codeplex really helps in any way: people who are interested only in IronRuby have to register now on codeplex and github, people who are interested in bot iron projects will have to register on both anyway. I don't see the number of content sites as a major problem. Rubyforge is being phased out in favor of better tools, so I don't think its a long term solution. (Even gem hosting has moved to rubygems.org<http://rubygems.org> instead of gems.rubyforge.org<http://gems.rubyforge.org>.) I don't think the ironruby.net<http://ironruby.net> site is holding the project back at all, but I agree it could be better. I think a better solution would be to replace it with a jekyll site running on GitHub. Just point the ironruby.net<http://ironruby.net> domain to GitHub and you're done. The reason I like the jekyll approach is because it makes it much easier for folks to create and improve web content. Its just a pull request away from being published. I think that system works really well, and its free. It doesn't really matter where downloads are hosted, as long as ironruby.net<http://ironruby.net> links to them. But they could just as easily be hosted on GitHub. The only thing that I'm aware is being used at CodePlex is the ticketing. Again, I think there are better ticketing solutions out there, most of them free for open source projects. I don't really see a need for CodePlex myself, but I understand the desire to stay on it for some things. Its probable that you could also push the jekyll content to CodePlex (and Rubyforge) if that was desired. I guess splitting up this this project is a nasty nasty dilemma, because the project tries to unite different communities which have different tool preferences. All the more reason to have separate repositories, IMO.
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
