Peter Bacon Darwin: > I believe one of the key problems is the DLR. As I understand, it MS > makes a distinction between "important" stuff (i.e. the DLR) and > "peripheral" stuff (i.e. IronXxxx). MS wants to have complete control > over the DLR and is not interested in making it Open Source. Rather > the DLR code is just community viewable, much like the rest of the > .NET framework code. I can understand this since core .NET Framework > code is central to the MS strategy and they don't want things sneaking > in the sides.
Minor correction to this point: The DLR is Open Source in as far as the license is concerned (which is not like the .NET Framework libraries source which is released under a much more restrictive read-only license), which works for folks who are interested in packaging / redistributing / forking. The DLR is does not accept contributions from the community, but feedback is certainly welcome. That said, the bar for feedback is set rather high on the DLR. Most folks are not compiler implementers, and that's the feedback that is needed there. Most folks working on libraries do not need to know anything about how the DLR is implemented (which is useful since that is changing rapidly right now). However, if you're building a language (we're doing 3) you have valuable feedback for the DLR team and that's one of the goals of IronRuby - to provide feedback to the DLR team. The reason why the DLR does not accept contributions from the community is because we intend to ship it in the next version of the .NET framework. And that means that it ships inside of our commercial products like Windows. Having community contributions in Windows is something that we simply cannot do today. > IronRuby, IronPython and so on are not so important to MS strategy and > they are more happy to let the community muck about with the code. I > believe that the long term goal is to open up the IronXxxx code much > more to the community but the problem is that the line between the DLR > and the IronXxxx languages is not yet nailed down. Therefore until > that happens MS is unlikely to hand over the project to the community. IronPython will move to an accept contributions from the community model soon. > I would be interested to know how often an SVN dump is created > compared to successful check-ins going through the SNAP process. > Ideally, every successful SNAP check-in should get automatically > dumped out on the RubyForge SVN repos, whether it added value or broke > the tests or whatever. You can always have SVN tags on the "good" > builds and also create downloadable "good" releases on the RubyForge > site - this point would probably help Justin Bailey's access problems too. Today we do not push to SVN on every successful SNAP check-in. That said, the process on my machine is more-or-less "rake to_svn", with a manual check-in after that. I would be more than happy to push on a daily basis. > Another scenario, which /M:D alludes to if I understand correctly, is > to allow the community to modify the code in the RubyForge project and > then let MS select "good" builds to check back into the Team system > via the SNAP process. That way, the community feels ownership of the > project and MS get that quality control on what finally goes into > IronRuby. > There are obviously many technical hurdles to overcome before this > could become reality. In particular, there needs to be a separation > of DLR from IronXxxx, including, probably, some kind of stable release > of the DLR for the IronXxxx projects to work off. Exactly. Right now the integrated model is good since it means that we progress faster. In the future, when we move to a modular model, it means that DLR changes will break IronRuby which means more work for everyone on this end (the DLR devs will be happier since they'll spend less time fixing us). The bottom line is that work is generated - it's just who feels the pain. > Any other ideas? John what are you thinking here? I collected my thoughts in the other thread that I started last night. Thanks for your ideas! -John _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
