[ruby-core:17562] Re: We'll release 1.8.6/1.8.7 this Friday

Michal Suchanek wrote:
> On 03/07/2008, M. Edward (Ed) Borasky <[e-mail]> wrote:
>> Wilson Bilkovich wrote:
>>
>>> On 7/3/08, Igal Koshevoy <[e-mail]> 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.
> 
> Setting up VMs for Windows or some BSDs should be easy. However, OS X
> cannot be virtualized so only people with apple hardware running that
> thing can test. There is the possibility to test on Darwin but it
> would be probably hard to set up environment identical to current OS
> X. There seem to be many people with OS X desktops but i am not sure
> there are many OS X servers free to run some untested code. Perhaps
> some best effort parallel execution like Seti@home could make things
> easier for exotic platforms.
> 
>>  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.
> 
> This could also work for *BSDs that use the GNU toolchain and ELF
> objects (but then there is only a small chance of platform specific
> bugs here). However, the tools on different platforms might vary
> wildly.
> 
> Thanks
> 
> Michal
> 
> 

I'm guessing at least 95 percent of Ruby issues could be found using 
just the latest GCC and its tools on a 64-bit GNU/Linux platform. :) If 
the source is clean with respect to that platform before handing it to 
the others, they will be "enabled" to focus their efforts on their 
platform-specific issues.

-- 
M. Edward (Ed) Borasky
http://ruby-perspectives.blogspot.com/

"A mathematician is a machine for turning coffee into theorems." -- Paul 
Erdos