On Sat, Oct 23, 2010 at 5:44 AM, Mike Moore <blowm...@gmail.com> wrote:
> On Oct 23, 2010, at 1:30 AM, Tomas Matousek <<tomas.matou...@microsoft.com> > tomas.matou...@microsoft.com> wrote: > > 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. > > You are speaking like someone responsible for both languages and the DLR. > And you are speaking like someone who has tried hard several times to contribute to IronRuby and failed because of a bloated project structure. I'm sure there are several people who would be willing to help you figure out what's wrong. Where's the repo with your contribution? > I'm making a suggestion as someone really only interested in IronRuby. The > repo isn't called "DynamicLanguages", it's called "IronRuby", which is at > best confusing. If only git had some way to define a link to another > repository as some sort of sub module... > Ah yes, and if only github had something like forking ... > > As a Rubyist I'd like to run a rake task to build to each defined target > and run the RubySpecs. It wouldn't replace xbuild, just automate it. I don't > understand the pushback to this idea. > If you want to create and maintain these, I'm sure no one would complain. I don't understand the push back to the idea that the three core contributors were a little tired of building IronRuby and maintaining two build approaches. I also don't understand a Rubyist's failure to see an opportunity to contribute rake tasks to a project. > Why not make a dedicated repo for IronRuby free of the ancillary projects > and geared to someone like me? And likewise make the IronPython repo > friendly to our Pythonic friends? > IronPython already has a separate repo at http://ironpython.codeplex.com/. > 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 J. 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. > > Unfortunately I do see how this could be simpler. > Great! Fork the project and show everyone! Sorry for the tone. If you were intending to come across differently, it would help offer help and not critique the great work Tomas and the rest have done. Try working on the project. Ask for help. You'll receive it readily. You may even find some people to help you restructure the project. If it works better, I'm sure you'll get support for moving the project to that structure. Just don't demand "your way right away" when you haven't contributed and don't understand the history. It's not your project yet. Get involved and make it yours. Ryan Riley Email: ryan.ri...@panesofglass.org LinkedIn: http://www.linkedin.com/in/ryanriley Twitter: @panesofglass Blog: http://wizardsofsmart.net/ Website: http://panesofglass.org/
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
