Has the team given up on continuous integration?
rake spec:ci hasn't passed in 3 months, maybe more. Is there any point to the suite of specs? Lost cause? Cheers, -Gp
Hi Gp, I'm not sure why you seem so upset. Here are the results of the CI: Library: files: 1043 examples: 1987 skipped examples: 748 expectations: 7548 failures: 0 errors: 0 pass rate: 72.65% Core: files: 1365 examples: 6635 skipped examples: 1438 expectations: 18752 failures: 2 errors: 0 pass rate: 82.19% Language: files: 61 examples: 1013 skipped examples: 96 expectations: 2635 failures: 0 errors: 0 pass rate: 91.34% Summary: files: 2469 examples: 9635 skipped examples: 2282 expectations: 28935 failures: 2 errors: 0 pass rate: 80.85% Exceptions: 1) Process.groups gets an Array of the gids of groups in the supplemental group access list FAILED Expected [12, 20, 62, 80, 98, 100, 204, 251, 253, 254, 257, 402, 404, 500, 501, 1025] to equal [12, 20, 62, 80, 98, 100, 204, 250, 251, 252, 253, 254, 255, 256, 257, 401, 402, 403, 404, 405, 406, 407, 500, 501, 502, 503, 504, 1025, 1027, 1028, 19000, 19002] core:in `raise:' core:in `each' core:in `all?' core:in `each' 2) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" core:in `raise:' core:in `each' core:in `all?' core:in `each' rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...] The first failure is bogus. So it lefts us with one failing spec related to the encodings that we currently don't fully support. Unless I'm missing something, this isn't bad at all. Maybe you're having other results on your system and is willing to try to help us finding out what's going on? - Matt On Mon, Dec 7, 2009 at 7:49 PM, Giampiero De Ciantis <gdeciantis@gmail.com>wrote:
rake spec:ci hasn't passed in 3 months, maybe more. Is there any point to the suite of specs? Lost cause?
Cheers,
-Gp _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Frustrated, not upset. I never trust a system where the CI has been red for this long. Here are the results I get, and they are fairly consistent. I don't know how you got the output you are showing, I am running "rake spec:ci" as described in the readme. Gps-iMac:MacRuby Gp$ rake spec:ci (in /Users/Gp/projects/MacRuby) ./mspec/bin/mspec ci -B ./spec/macruby.mspec :full MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x7fff7037cbe0) malloc: *** auto malloc[47790]: error for object 0x1036d46d0: auto_zone_set_associative_ref: object should point to a GC block or a global address, otherwise associations will leak. Break on auto_zone_association_error() to debug. ...............................................................................................................................................................................................................................................................................................................................................................................F........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x10bb81000) malloc: reference count underflow for 0x20210edc0, break on auto_refcount_underflow_error to debug. .....macruby(47790,0x10bb81000) malloc: reference count underflow for 0x2020d9320, break on auto_refcount_underflow_error to debug. ..macruby(47790,0x10bb81000) malloc: reference count underflow for 0x202135260, break on auto_refcount_underflow_error to debug. ...................................................................................................................................................................................................................................F................................................................................................................................................................................................................................................ 1) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" core:in `raise:' core:in `each' core:in `all?' core:in `each' 2) TCPServer.new raises a SocketError when the host is unknown FAILED Expected SocketError but got Errno::EADDRNOTAVAIL (Can't assign requested address - bind(2)) core:in `raise:' Finished in 162.793482 seconds 2469 files, 9637 examples, 28937 expectations, 2 failures, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...] (See full trace by running task with --trace) In my case you can see 2 failures and a few exceptions being thrown which is troubling (is the Rake task supposed to abort at the end too?). And as you can see I am getting different failures than you are. I am trying to help, but my C skills are weaker than my ruby (or pretty much any other language) and the code is not easy to work with. However, after reading more and more I am starting to understand how the C code affects the Ruby runtime. But every time I have pulled down a new version of the code to see if I can add or fix something, I hope that the CI suite will pass so that I can start from green and then tinker, but the suite hasn't passed in a while. When it was isolated failures, I felt Ok, but the the malloc exceptions and the like give me definite pause. I am not confident enough to fiddle around with stuff when the whole system is showing this many failures. False positives make me more cautious. If I hand you a patch, I want to say "the CI is still passing", but I can never say that. Cheers, -Gp On 2009-12-07, at 11:11 PM, Matt Aimonetti wrote:
Hi Gp,
I'm not sure why you seem so upset. Here are the results of the CI:
Library: files: 1043 examples: 1987 skipped examples: 748 expectations: 7548 failures: 0
errors: 0 pass rate: 72.65%
Core: files: 1365 examples: 6635 skipped examples: 1438 expectations: 18752 failures: 2 errors: 0 pass rate: 82.19%
Language: files: 61
examples: 1013 skipped examples: 96 expectations: 2635 failures: 0 errors: 0 pass rate: 91.34%
Summary: files: 2469 examples: 9635 skipped examples: 2282 expectations: 28935
failures: 2 errors: 0 pass rate: 80.85%
Exceptions:
1) Process.groups gets an Array of the gids of groups in the supplemental group access list FAILED Expected [12, 20, 62, 80, 98, 100, 204, 251, 253, 254, 257, 402, 404, 500, 501, 1025]
to equal [12, 20, 62, 80, 98, 100, 204, 250, 251, 252, 253, 254, 255, 256, 257, 401, 402, 403, 404, 405, 406, 407, 500, 501, 502, 503, 504, 1025, 1027, 1028, 19000, 19002] core:in `raise:' core:in `each'
core:in `all?' core:in `each'
2) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")"
core:in `raise:' core:in `each' core:in `all?' core:in `each' rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...]
The first failure is bogus. So it lefts us with one failing spec related to the encodings that we currently don't fully support.
Unless I'm missing something, this isn't bad at all. Maybe you're having other results on your system and is willing to try to help us finding out what's going on?
- Matt
On Mon, Dec 7, 2009 at 7:49 PM, Giampiero De Ciantis <gdeciantis@gmail.com> wrote: rake spec:ci hasn't passed in 3 months, maybe more. Is there any point to the suite of specs? Lost cause?
Cheers,
-Gp _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi, See my replies inline.
Frustrated, not upset. I never trust a system where the CI has been red for this long.
Here are the results I get, and they are fairly consistent. I don't know how you got the output you are showing, I am running "rake spec:ci" as described in the readme.
Gps-iMac:MacRuby Gp$ rake spec:ci (in /Users/Gp/projects/MacRuby) ./mspec/bin/mspec ci -B ./spec/macruby.mspec :full MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x7fff7037cbe0) malloc: *** auto malloc[47790]: error for object 0x1036d46d0: auto_zone_set_associative_ref: object should point to a GC block or a global address, otherwise associations will leak. Break on auto_zone_association_error() to debug. ...............................................................................................................................................................................................................................................................................................................................................................................F........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x10bb81000) malloc: reference count underflow for 0x20210edc0, break on auto_refcount_underflow_error to debug. .....macruby(47790,0x10bb81000) malloc: reference count underflow for 0x2020d9320, break on auto_refcount_underflow_error to debug. ..macruby(47790,0x10bb81000) malloc: reference count underflow for 0x202135260, break on auto_refcount_underflow_error to debug. ...................................................................................................................................................................................................................................F................................................................................................................................................................................................................................................
1) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" core:in `raise:' core:in `each' core:in `all?' core:in `each'
2) TCPServer.new raises a SocketError when the host is unknown FAILED Expected SocketError but got Errno::EADDRNOTAVAIL (Can't assign requested address - bind(2)) core:in `raise:'
Finished in 162.793482 seconds
2469 files, 9637 examples, 28937 expectations, 2 failures, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...]
(See full trace by running task with --trace)
In my case you can see 2 failures and a few exceptions being thrown which is troubling (is the Rake task supposed to abort at the end too?). And as you can see I am getting different failures than you are.
The reason that one of the two failures is different has probably more to do with the environment being different, ie the alternative formatter subtly changes something. And as Matt said, the String#dump failure is one that can't be helped right now, so you should consider this to be ‘green’. Or better yet, you could fix these. And yes, Rake always ‘aborts’ if a system call did not exit status 0. So don't worry about that.
I am trying to help, but my C skills are weaker than my ruby (or pretty much any other language) and the code is not easy to work with. However, after reading more and more I am starting to understand how the C code affects the Ruby runtime.
Yes! Please don't stop :)
But every time I have pulled down a new version of the code to see if I can add or fix something, I hope that the CI suite will pass so that I can start from green and then tinker, but the suite hasn't passed in a while. When it was isolated failures, I felt Ok, but the the malloc exceptions and the like give me definite pause.
Don't worry about those right now. Why? Just don't, the people that know why will look into it when the time is right.
I am not confident enough to fiddle around with stuff when the whole system is showing this many failures.
There are only _two_ failures in both your output, not that many imo. That's nothing compared to how many we still have tagged. Also, did you know that MRI surely has more than two failing examples in the RubySpec at any given time? This so you can put it into perspective.
False positives make me more cautious. If I hand you a patch, I want to say "the CI is still passing", but I can never say that.
I understand your worries, but you can in fact do this. Just make sure to run them _before_ patching and then compare afterwards. This is how I've been working on, for instance, Rails as well. HTH, Eloy
Thanks Eloy. I'll take my panic pants off and get it at it again. I feel somewhat sheepish since I have been trolling through this code for months (I think a year now) and haven't been able to submit a single patch. But I will continue to try. Cheers, -Gp On 2009-12-08, at 7:55 AM, Eloy Duran wrote:
Hi,
See my replies inline.
Frustrated, not upset. I never trust a system where the CI has been red for this long.
Here are the results I get, and they are fairly consistent. I don't know how you got the output you are showing, I am running "rake spec:ci" as described in the readme.
Gps-iMac:MacRuby Gp$ rake spec:ci (in /Users/Gp/projects/MacRuby) ./mspec/bin/mspec ci -B ./spec/macruby.mspec :full MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x7fff7037cbe0) malloc: *** auto malloc[47790]: error for object 0x1036d46d0: auto_zone_set_associative_ref: object should point to a GC block or a global address, otherwise associations will leak. Break on auto_zone_association_error() to debug. ...............................................................................................................................................................................................................................................................................................................................................................................F........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x10bb81000) malloc: reference count underflow for 0x20210edc0, break on auto_refcount_underflow_error to debug. .....macruby(47790,0x10bb81000) malloc: reference count underflow for 0x2020d9320, break on auto_refcount_underflow_error to debug. ..macruby(47790,0x10bb81000) malloc: reference count underflow for 0x202135260, break on auto_refcount_underflow_error to debug. ...................................................................................................................................................................................................................................F................................................................................................................................................................................................................................................
1) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" core:in `raise:' core:in `each' core:in `all?' core:in `each'
2) TCPServer.new raises a SocketError when the host is unknown FAILED Expected SocketError but got Errno::EADDRNOTAVAIL (Can't assign requested address - bind(2)) core:in `raise:'
Finished in 162.793482 seconds
2469 files, 9637 examples, 28937 expectations, 2 failures, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...]
(See full trace by running task with --trace)
In my case you can see 2 failures and a few exceptions being thrown which is troubling (is the Rake task supposed to abort at the end too?). And as you can see I am getting different failures than you are.
The reason that one of the two failures is different has probably more to do with the environment being different, ie the alternative formatter subtly changes something. And as Matt said, the String#dump failure is one that can't be helped right now, so you should consider this to be ‘green’. Or better yet, you could fix these.
And yes, Rake always ‘aborts’ if a system call did not exit status 0. So don't worry about that.
I am trying to help, but my C skills are weaker than my ruby (or pretty much any other language) and the code is not easy to work with. However, after reading more and more I am starting to understand how the C code affects the Ruby runtime.
Yes! Please don't stop :)
But every time I have pulled down a new version of the code to see if I can add or fix something, I hope that the CI suite will pass so that I can start from green and then tinker, but the suite hasn't passed in a while. When it was isolated failures, I felt Ok, but the the malloc exceptions and the like give me definite pause.
Don't worry about those right now. Why? Just don't, the people that know why will look into it when the time is right.
I am not confident enough to fiddle around with stuff when the whole system is showing this many failures.
There are only _two_ failures in both your output, not that many imo. That's nothing compared to how many we still have tagged. Also, did you know that MRI surely has more than two failing examples in the RubySpec at any given time? This so you can put it into perspective.
False positives make me more cautious. If I hand you a patch, I want to say "the CI is still passing", but I can never say that.
I understand your worries, but you can in fact do this. Just make sure to run them _before_ patching and then compare afterwards. This is how I've been working on, for instance, Rails as well.
HTH, Eloy _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Gp, thanks for keeping on our toes ;) - Matt On Tue, Dec 8, 2009 at 8:06 AM, Giampiero De Ciantis <gdeciantis@gmail.com>wrote:
Thanks Eloy. I'll take my panic pants off and get it at it again.
I feel somewhat sheepish since I have been trolling through this code for months (I think a year now) and haven't been able to submit a single patch. But I will continue to try.
Cheers,
-Gp
On 2009-12-08, at 7:55 AM, Eloy Duran wrote:
Hi,
See my replies inline.
Frustrated, not upset. I never trust a system where the CI has been red for this long.
Here are the results I get, and they are fairly consistent. I don't know how you got the output you are showing, I am running "rake spec:ci" as described in the readme.
Gps-iMac:MacRuby Gp$ rake spec:ci (in /Users/Gp/projects/MacRuby) ./mspec/bin/mspec ci -B ./spec/macruby.mspec :full MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x7fff7037cbe0) malloc: *** auto malloc[47790]: error for object 0x1036d46d0: auto_zone_set_associative_ref: object should point to a GC block or a global address, otherwise associations will leak. Break on auto_zone_association_error() to debug. ...............................................................................................................................................................................................................................................................................................................................................................................F........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby(47790,0x10bb81000) malloc: reference count underflow for 0x20210edc0, break on auto_refcount_underflow_error to debug. .....macruby(47790,0x10bb81000) malloc: reference count underflow for 0x2020d9320, break on auto_refcount_underflow_error to debug. ..macruby(47790,0x10bb81000) malloc: reference count underflow for 0x202135260, break on auto_refcount_underflow_error to debug.
...................................................................................................................................................................................................................................F................................................................................................................................................................................................................................................
1) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" core:in `raise:' core:in `each' core:in `all?' core:in `each'
2) TCPServer.new raises a SocketError when the host is unknown FAILED Expected SocketError but got Errno::EADDRNOTAVAIL (Can't assign requested address - bind(2)) core:in `raise:'
Finished in 162.793482 seconds
2469 files, 9637 examples, 28937 expectations, 2 failures, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...]
(See full trace by running task with --trace)
In my case you can see 2 failures and a few exceptions being thrown which is troubling (is the Rake task supposed to abort at the end too?). And as you can see I am getting different failures than you are.
The reason that one of the two failures is different has probably more to do with the environment being different, ie the alternative formatter subtly changes something. And as Matt said, the String#dump failure is one that can't be helped right now, so you should consider this to be ‘green’. Or better yet, you could fix these.
And yes, Rake always ‘aborts’ if a system call did not exit status 0. So don't worry about that.
I am trying to help, but my C skills are weaker than my ruby (or pretty much any other language) and the code is not easy to work with. However, after reading more and more I am starting to understand how the C code affects the Ruby runtime.
Yes! Please don't stop :)
But every time I have pulled down a new version of the code to see if I can add or fix something, I hope that the CI suite will pass so that I can start from green and then tinker, but the suite hasn't passed in a while. When it was isolated failures, I felt Ok, but the the malloc exceptions and the like give me definite pause.
Don't worry about those right now. Why? Just don't, the people that know why will look into it when the time is right.
I am not confident enough to fiddle around with stuff when the whole system is showing this many failures.
There are only _two_ failures in both your output, not that many imo. That's nothing compared to how many we still have tagged. Also, did you know that MRI surely has more than two failing examples in the RubySpec at any given time? This so you can put it into perspective.
False positives make me more cautious. If I hand you a patch, I want to say "the CI is still passing", but I can never say that.
I understand your worries, but you can in fact do this. Just make sure to run them _before_ patching and then compare afterwards. This is how I've been working on, for instance, Rails as well.
HTH, Eloy _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
No problem , like Matt said, thanks for keeping us on our toes :) I think the best way to do so is to have a goal. So pick a lib you know you need: * Run it in a sample or its test suite * Wheep and moan in a corner ;) * Grab coffee * Pick a failure and lookup the specs of that functionality * Start hacking and asking Cheers, Eloy On 8 dec 2009, at 17:06, Giampiero De Ciantis wrote:
Thanks Eloy. I'll take my panic pants off and get it at it again.
I feel somewhat sheepish since I have been trolling through this code for months (I think a year now) and haven't been able to submit a single patch. But I will continue to try.
Cheers,
-Gp
On 2009-12-08, at 7:55 AM, Eloy Duran wrote:
Hi,
See my replies inline.
Frustrated, not upset. I never trust a system where the CI has been red for this long.
Here are the results I get, and they are fairly consistent. I don't know how you got the output you are showing, I am running "rake spec:ci" as described in the readme.
Gps-iMac:MacRuby Gp$ rake spec:ci (in /Users/Gp/projects/MacRuby) ./mspec/bin/mspec ci -B ./spec/macruby.mspec :full MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] ..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby (47790,0x7fff7037cbe0) malloc: *** auto malloc[47790]: error for object 0x1036d46d0: auto_zone_set_associative_ref: object should point to a GC block or a global address, otherwise associations will leak. Break on auto_zone_association_error() to debug. ...............................................................................................................................................................................................................................................................................................................................................................................F ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................macruby (47790,0x10bb81000) malloc: reference count underflow for 0x20210edc0, break on auto_refcount_underflow_error to debug. .....macruby(47790,0x10bb81000) malloc: reference count underflow for 0x2020d9320, break on auto_refcount_underflow_error to debug. ..macruby(47790,0x10bb81000) malloc: reference count underflow for 0x202135260, break on auto_refcount_underflow_error to debug. ...................................................................................................................................................................................................................................F ................................................................................................................................................................................................................................................
1) String#dump includes .force_encoding(name) if the encoding isn't ASCII compatiable FAILED Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")" core:in `raise:' core:in `each' core:in `all?' core:in `each'
2) TCPServer.new raises a SocketError when the host is unknown FAILED Expected SocketError but got Errno::EADDRNOTAVAIL (Can't assign requested address - bind (2)) core:in `raise:'
Finished in 162.793482 seconds
2469 files, 9637 examples, 28937 expectations, 2 failures, 0 errors rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/ macruby.msp...]
(See full trace by running task with --trace)
In my case you can see 2 failures and a few exceptions being thrown which is troubling (is the Rake task supposed to abort at the end too?). And as you can see I am getting different failures than you are.
The reason that one of the two failures is different has probably more to do with the environment being different, ie the alternative formatter subtly changes something. And as Matt said, the String#dump failure is one that can't be helped right now, so you should consider this to be ‘green’. Or better yet, you could fix these.
And yes, Rake always ‘aborts’ if a system call did not exit status 0. So don't worry about that.
I am trying to help, but my C skills are weaker than my ruby (or pretty much any other language) and the code is not easy to work with. However, after reading more and more I am starting to understand how the C code affects the Ruby runtime.
Yes! Please don't stop :)
But every time I have pulled down a new version of the code to see if I can add or fix something, I hope that the CI suite will pass so that I can start from green and then tinker, but the suite hasn't passed in a while. When it was isolated failures, I felt Ok, but the the malloc exceptions and the like give me definite pause.
Don't worry about those right now. Why? Just don't, the people that know why will look into it when the time is right.
I am not confident enough to fiddle around with stuff when the whole system is showing this many failures.
There are only _two_ failures in both your output, not that many imo. That's nothing compared to how many we still have tagged. Also, did you know that MRI surely has more than two failing examples in the RubySpec at any given time? This so you can put it into perspective.
False positives make me more cautious. If I hand you a patch, I want to say "the CI is still passing", but I can never say that.
I understand your worries, but you can in fact do this. Just make sure to run them _before_ patching and then compare afterwards. This is how I've been working on, for instance, Rails as well.
HTH, Eloy _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Dec 8, 2009, at 4:01 AM, Giampiero De Ciantis wrote:
Frustrated, not upset. I never trust a system where the CI has been red for this long.
RubySpec doesn't cover everything. I recommend that you build a project and report us regressions. The "CI" system you refer to is only meant to be used by those who hack on MacRuby, as a tool to measure compatibility and eventually detect regressions. This being said, if you're frustrated by the spec failures, feel free to send a patch. Laurent
participants (4)
-
Eloy Duran
-
Giampiero De Ciantis
-
Laurent Sansonetti
-
Matt Aimonetti