From: Luis Lavena Date: 2011-09-09T08:34:05+09:00 Subject: [ruby-core:39389] Re: RubySpec vs CRuby's test/... On Thu, Sep 8, 2011 at 7:40 PM, SASADA Koichi wrote: > (2011/09/08 15:28), Charles Oliver Nutter wrote: >> THE NEED: > > > Thank you for summary of needs. �Following is problems I feel (and > discussed on IRC). > Hello Koichi-san, > Problems: > > (1) Most of MRI developers (is it true?) can't change RubySpec. �Also > most of MRI developers don't know RubySpec rules. > Commit bit can be given to the ones that ask, they just need a GitHub account. RubySpec rules are clearly detailed here: http://rubyspec.org/ Getting Started: http://rubyspec.org/getting_started/ How RubySpec is organized: http://rubyspec.org/organization/ The Style Guide: http://rubyspec.org/style_guide/ Guards for platforms, Ruby versions, bugs and implementation compliance: http://rubyspec.org/guards/ The matchers availables (expectations): http://rubyspec.org/matchers/ > (2) We can add code modification and test cases in one commit. �If we > can't do it, we need commit commit modifications and RubySpec isolation. > I believe that tests that fix bugs in MRI can be done in a single commit. Changes in MRI that do change the behavior of Ruby itself need to be reflected in RubySpec. If not, how other implementations will match? > (3) It is difficult to judge test is an independent or not. > Additionally, we don't need to insert "guard" about version or > implementation on our "test/*". �It seems tough work to insert correct > "guard". > > (4) Current RubySpec is not portable (especially Windows) > [ruby-core:39379]. > RubySpec is portable, see [ruby-core:39382] > (5) As you know, trunk is not unstable. �For example, some modifications > are revertd soon. �Should we add such features as "Specifications"? �(I > know that there is an opinion that the experimental code should have a > spec). > When a feature gets stable/solid, documentation of it in RubySpec should be done. > (6) test/* contains many many corner cases depend on MRI implementation > to increase code coverage (Thanks Endo-san). �It is independent as Ruby > language, but dependent on MRI. �Where should we write such tests? > corner cases for MRI, things that fix MRI specific bug or behavior are for MRI test/* only. Things that affect and define Ruby language should be added to RubySpec > > I think this problem is "who pay efforts on it?". > We all pay, MRI and other implementation developers pay the price. There is no consolidated place of reference to look into the language specification. > One solution is continuing current style (using test/*) and someone > migrate tests to RubySpec if needed. �But we need "someone". > > Other solution is MRI committer join to maintain RubySpec. �MRI > developer (including me) should change development style and several > overhead to do (I think inserting correct "guard" is difficult). > > Brian Ford told me that we can have our own RubySpec repository in MRI > repository and migrating updating specs from MRI's RubySpec repository > to the RubySpec repository is easy. �It is also one solution. �However, > we need "someone" who can migrate. �It solves (1), (2) and maybe (3). > In my personal opinion, the developer who change the behavior of Ruby should be the one adding or correcting the proper specs in RubySpec (either the MRI mirror or the common one) -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup�ry