[Ironruby-core] Regarding IronRuby... How true it sounds from this blog

John Lam (IRONRUBY) jflam at microsoft.com
Tue Apr 29 10:06:57 EDT 2008

M. David Peterson:

> I agree.  If I am remembering correctly, one of the primary reasons
> behind the dual-repository approach is the need to run a myriad of
> internal tests  from a test suite that reaches farther and deeper than
> just IronRuby, and therefore can not see the light of day outside the
> MSFT firewall.

There are several issues around this. We run our tests against internal drops of Silverlight (remember we're building IronRuby while simultaneously building DLR *and* CoreCLR). Externals won't be able to see this stuff, and to keep our tree consistent we need to continue to test and run against CoreCLR.

> John, is this an accurate assessment?  If yes, while I certainly
> recognize the need to run the code against internal test suites,
> couldn't it be looked at from the opposite perspective?That of: We, the
> community, tell you, the big bad corporate firewall, when you get to
> gain access to *our* code to run your tests.  We will continue on our
> way checking it whatever we want whenever we want, and you can use
> repository revisions as a marker to determine what can be viewed as
> "blessed" and what can not as far as releases are concerned.

This is largely a philosophical issue - do you want to resolve build breaks when you sync or do you want to resolve build breaks when you commit. The former is worse than the latter, especially when it takes a significant amount of time to see if things work (40 minutes today).

> If it takes a few extra weeks to take a particular
> revision of the repository through the internal ringer before getting
> the official rubber stamp, then so be it.

> It wouldn't be getting in the way of development progress, and if not
> mistaken, this is really the core of the argument as to why the process
> is currently broken.

This will impede progress a lot more than you think it would ... remember - you're writing library code on top of a changing IronRuby compiler + runtime which itself is built on top of a changing DLR which is itself built on top of a changing CoreCLR (aka Silverlight CLR). One of our DLR devs recently spent 30 hours debugging a buffer overrun in a daily build of CoreCLR that was fixed in a subsequent build. Is this the world that you really want to live in?


More information about the Ironruby-core mailing list