I don't understand how three distinct github repos that I need to map into some directories on my disk whose relative location to each other is hardcoded in some scripts in each are better than a single repo that has a well-defined structure.
The amount of code you need to know depends on the part you contribute to. If you work on IronRuby libraries you don't need to even look at IronPython. It is indeed better to look there because similar functionality might already be implemented there. For example, if you worked on FFI you might want to check out IronPython's CTypes and perhaps reuse some code. Why would you need to understand the entire code base if you needed to do a local change? Just don't look where you don't need to :). Building IronRuby is also simple - you just run xbuild Ruby.sln from Solution directory. Subsequent builds are incremental, so you don't even need to build everything if you don't change core components. I don't see how this could be any simpler. Tomas From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Mike Moore Sent: Friday, October 22, 2010 8:27 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Contributing? On Fri, Oct 22, 2010 at 6:59 PM, Tomas Matousek <tomas.matou...@microsoft.com<mailto:tomas.matou...@microsoft.com>> wrote: 2) It is not a holdover. It makes a lot of sense actually for at least the following reasons: a) Some IronRuby tests test interop between these languages. So there is a direct dependency. When you debug issues in language interop you need to have IronPython source code as well to step thru and make sense of the interactions. I don't understand why the code needs to exist within the same git repo for this then. Can you not have a Visual Studio solution that includes multiple projects with their own repository? Can't you have your automated build system pull both the IronRuby and IronPython projects to run the integration tests? b) DLR has two parts - the "inner ring" that shipped in .NET Framework 4.0 and the "outer ring", which hasn't shipped. Although the outer ring is pretty stable there are still many improvements that can/should be done. Obviously when you change the DLR you should run tests for both languages so that you don't break anything. Thus IronPython's test suite in the repo is handy. Also, if you change public API in the outer ring you might need to change both IronPython and IronRuby. All of this could be done in stages across different repos and even source control systems, but that's obviously much more complicated than having it just work. I assumed the DLR was fixed. If that is not the case then shouldn't the DLR should be its own separate git repo as well? Is size of the repo really an issue? If not, what is? No, its not the size of the repo, rather the amount of tangental code. As someone who hasn't looked at the code for well over a year, I am struck by the amount of orthogonal concerns that are front and center. I find it too busy and off-putting as a developer looking to become familiar with the code or make a small contribution. I don't doubt there aren't reasons it is the way it is, just that it can be better if you want to really open the floodgates of contributions.
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
