First, thank you (and Evan especially) for the tone you are setting regarding Rubinius on Windows. I strongly believe setting the right tone is crucial for success. It continually reminds us of the big picture and leads-by-example for project newcomers.
I'd like to suggest the following ideas for discussion on ways to enable Rubinius on Windows without slowing down core development. While it depends upon Windows developers getting involved in meaningful ways, I feel it's important to have an environment that makes it easy to contribute and accept contributions. 1) To manage scope, document Rubinius's goals and non-goals wrt the Windows platform. Something similar to http://rubini.us/about/roadmap tuned for specific Window's goals and non-goals. For example, unresolved core issues (IO?) such as "...Ruby 1.9.1 on Linux is about 70% faster than the Windows version..." from http://antoniocangiano.com/2009/08/10/how-much-faster-is-ruby-on-linux/ do nothing to build credibility that an implementation is ready for primetime production on multiple platforms. While "ready for primetime production on ??? platforms" may be a non-goal, please be explicit. 2) Identify a core Technical Lead responsible for merging windows-specific patches into master. I suspect many of you are cringing at this idea, and perhaps one of you has already has the short straw ;) However, this could be a short-term responsibility as more experienced windows developers get involved with Rubinius. If someone with more windows-specific experience and passion for windows does get involved, the Tech Lead responsibilities could easily be transitioned. Having someone responsible for setting expectations and prioritizing to ensure the windows issues (a) are handled in a timely manner, and (b) mesh well with the existing code base, is key. 3) Identify and prioritize the crucial Rubinius-on-Windows tasks. Focus. While potentially enticing, does Rubinius really need a Ragel-created build language parsing engine!? Document the tasks on a wiki page at http://github.com/evanphx/rubinius As the tasks stabilize, they can be integrated with the rubini.us website. As windows developers get interested and want to know how to help, point them to the wiki page. It's also important to list tasks that can be solved by those who may only time to make Drive-by-Contributions. Suggested Rubininus-on-Windows tasks: a1) Build (MacPorts or APT) a binary 7-zip archive for Windows testing using the mingw32 cross compiler a2) Discover and document a readily available build environment that enables reliable windows-based builds...first target? * Msys, bison-2.4.1 * Mingw: gcc-core-4.4.0, gcc-c++-4.4.0, mingwrt-3.18, w32api-3.14 (sync with "apt-get install mingw32" versions instead?) * gdb-7.0.50 * libz-1.2.3-mingw * Ruby 1.8.7 from http://rubyinstaller.org/ * Pik (Ruby version manager for windows) http://github.com/vertiginous/pik b) Run Rubinius's core tests and run key RubyGems (Rake, RSpec, Rails, Cucumber, Nokogiri, Sinatra, Thin, Sequel, DataMapper, Sqlite3-ruby, mongo_ext, Bundler, ???). Report issues at http://github.com/evanphx/rubinius/issues c) Run Linux-v-Windows and multi-ruby-implementation performance test using http://github.com/acangiano/ruby-benchmark-suite d) Develop a Wix or InnoSetup based installer e) Documentation, blog, screencast Jon -- --- !ruby/object:MailingList name: rubinius-dev view: http://groups.google.com/group/rubinius-dev?hl=en post: [email protected] unsubscribe: [email protected]
