Thanks for the discussions in the rather long thread today. I wanted to start a new thread under a better subject heading to continue the discussion.
I'll be the first to admit that we suffer from the problem where we work on a different source code repository, with an internal-only testing infrastructure, and different internal tools. This causes friction and pain for a lot of folks, and to be blunt there are no simple fixes to this. Everything here involves a trade-off and it boils down to who's going to feel the pain at this point. So let's summarize what most folks would like to see: 1. Move the primary repository to SVN with TFS as our mirror. 2. Move more communication into the external mailing list 3. Release of binaries 4. Scrum-like status updates on the list So let's talk about a few of these issues in turn. 1. SVN as primary repository. This won't happen for several reasons. First, we have effectively four different teams (IronRuby, IronPython, Managed JScript and DLR) working on the same codebase. Only the IronRuby team is on RubyForge (yes, we also drop the DLR sources there, but that's a convenience thing for y'all and not a permanent place for those sources). As the DLR is changed in our TFS repository, it is the responsibility of the dev making those changes to ensure that they don't break any of the languages (and to fix them if the change breaks them). Today we gain the advantage of tight integration between these four projects. The DLR can evolve rapidly which is goodness for folks on the outside. Remember - we're building the platform and the languages in parallel here. Second, we do run what folks would call a continuous integration server. I call it the troll that guards 'the truth' in our repository. When a dev wants to commit code to our repository they need to run those changes past the troll. The troll runs a comprehensive suite of check-in tests against the changes before it commits them to the repository after a successful test run. This provides pretty strong guarantees that the tree is in a consistent state which means that things continue to work when you pull the latest sources. That's much better than the alternative which means that you spend time tracking down build breaks after you sync. The troll has strong dependencies on TFS, and would be very difficult to replicate outside of the company (the troll is really 20 servers inside one of our labs). 2. Move more communication onto the external mailing list This is totally doable, and something we should have done for some time now. What I'm now proposing is this: all IronRuby code reviews will go out through the public mailing list. We will generate a TFS 'unified diff' (http://msdn2.microsoft.com/en-us/library/6fd7dc73.aspx) and attach that diff to the code review email that will be CC'd to ironruby-core. This way you'll have the context for the changes (the source code) along with a detailed email that describes what those changes are, along with some commentary. Note that complex changes are often reviewed face-to-face on our team (think pair-reviewing). But many changes are reviewed entirely by email, so those follow-on emails will be captured for all to see. 3. Release of binaries There is nothing blocking this today, and since we're in a better position to let folks 'kick the tires' these days, I'll add binaries to our repository. 4. Scrum-like status updates to the list This makes sense and I'll talk tomorrow to Tomas and Jim about what we'll do from this point forward. Note that these are just *my* ideas at this point. I'd like to use this as a kick-off for some broader discussions on other issues that are on your mind. Thanks, -John _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
