[#67346] Future of test suites for Ruby — Charles Oliver Nutter <headius@...>
I'll try to be brief so we can discuss all this. tl;dr: RubySpec is
19 messages
2015/01/05
[#67353] Re: Future of test suites for Ruby
— Tanaka Akira <akr@...>
2015/01/05
2015-01-06 7:18 GMT+09:00 Charles Oliver Nutter <headius@headius.com>:
[#67444] [ruby-trunk - Feature #10718] [Open] IO#close should not raise IOError on closed IO objects. — akr@...
Issue #10718 has been reported by Akira Tanaka.
3 messages
2015/01/09
[#67689] Keyword Arguments — Anthony Crumley <anthony.crumley@...>
Please forgive my ignorance as I am new to MRI development and am still
5 messages
2015/01/20
[#67733] [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5 — normalperson@...
Issue #10761 has been updated by Eric Wong.
4 messages
2015/01/21
[#67736] Re: [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5
— Eric Wong <normalperson@...>
2015/01/22
normalperson@yhbt.net wrote:
[#67772] Preventing Redundant Email Messages — Jeremy Evans <code@...>
For a long time, I've wondered why I sometimes receive redundant email
5 messages
2015/01/23
[ruby-core:67355] Re: Future of test suites for Ruby
From:
Eric Wong <normalperson@...>
Date:
2015-01-06 02:33:46 UTC
List:
ruby-core #67355
Charles Oliver Nutter <headius@headius.com> wrote:
> * Begin an effort to bring missing tests from RubySpec into MRI's
> suite and to clean up and improve MRI's suite. Abandon RubySpec at
> some point.
This is ideal (but also a lot of effort). Other Ruby implementations
ought to be able to use MRI's test suite easily.
> I don't like the idea of abandoning RubySpec, since it has many
> valuable features.
Valuable features outside of specs themselves? Can you elaborate?
Like akr, I prefer a smaller test library with fewer surprises to ease
debugging. One recent example was Bug #10685 where you and Chris both
had trouble reproducing the test as a standalone case.
> * Take over RubySpec as a fork and begin to maintain it as a secondary
> suite for MRI. Encourage contributors and committers to write specs
> rather than tests.
>
> I think this is possible. The barrier to contributing to RubySpec is
> much lower if we're maintaining a fork of it, and I think that
> eliminates many obstacles. I also feel like the future needs to be in
> either RubySpec or a much cleaner version of MRI's suite, and there's
> less work to start using the former now.
I wouldn't mind this, except there's a major barrier to some folks
(OK, perhaps I'm the only one :<):
Contributing to RubySpec requires an account and accepting a
Terms-of-Service on a proprietary service provider.
We use Ruby freely without accepting any ToS from for-profit
company; so I hope we may all contribute without jumping through
that hoop as well.