Wilson Bilkovich wrote:
> On 7/3/08, Igal Koshevoy <igal / pragmaticraft.com> wrote:
>> Charles Oliver Nutter wrote:
>>
>>> Igal Koshevoy wrote:
>>>
>>>> Please delay the release. I don't think we'll be able to resolve the
>> remaining critical issues by Friday.
>>> For what it's worth, this is all a strong argument for having a CI server
>> and keeping rubyspec "green" all the time. Nobody likes having to delay a
>> release because there's a stack of errors to be dealt with.
>>  Absolutely.
>>
>>  Is anyone providing CI for Ruby releases? Is there a good CI tool written
>> in Ruby? Would Hudson be acceptable for doing Ruby stuff? Is JRuby or one of
>> the other alternative implementations using something for CI that they're
>> happy with?
>>
>>  I've been building up a shell script, mostly for personal use, so I can run
>> the checks against various test suites. I attached an earlier version with
>> my bug report #199 asking for patch reviews. I can mop that script up a bit
>> and release versions so that others can run the full suite of tests
>> on-demand from their  command line and or from a CI server. I've been
>> building this as a shell script because it minimizes dependencies so that as
>> long as the user has bash, svn, git, wget, tar and maybe a tiny number of
>> other utilities, they can run it. Does this sound useful?
>>
>>  I also talked earlier about setting up a bunch of VMs running different
>> OSes and running the test scripts against these, which would be a good way
>> to catch platform-specific issues. Is there interest in such a thing?
>>
>>  However, if someone's already done this effort, it'd be good to know so we
>> can take a look at it and possibly build upon it instead.
>>
> 
> Ryan Davis is working on a system for this right now. Last I heard, it
> is nearing completion.
> 
> 

Glad to hear it. I've got some spare cycles (day job starts again 8 
July.) :) I was about to start up on this, but if someone is doing it, 
I'll wait. My own thinking was to do

1. Check out Ruby 1.8.6 from SVN.
2. Compile with GCC 4.3.1 with the "gcov" coverage analysis and debug 
options. I only have an AMD64 dual-core and 4 GB of RAM running Gentoo 
Linux, not a buncha VMs with every conceivable environment. For other 
environmental reasons, I compile *with* threads.
3. Run all the test suites and benchmark suites (someday, we really 
should merge those.) :)
4. Post the code coverage analysis, test suite results, and tracebacks 
for any crashes "somewhere". I've got "oprofile" working, so I can also 
post profiles if anyone cares.

I'm definitely going to do the benchmarks; this started out as a 
profiling exercise on Rubinius. :) A Rakefile would be nice, but I am a 
terrible Rakefile writer -- for some reason, I can't do "DRY" Rakefiles. 
I usually end up just defining a whole bunch of Ruby methods to make a 
sensibly factored set of code, which seems somehow "un-Rake-like." :)