[ruby-core:39389] Re: RubySpec vs CRuby's test/...

On Thu, Sep 8, 2011 at 7:40 PM, SASADA Koichi <[e-mail]> wrote:
> (2011/09/08 15:28), Charles Oliver Nutter wrote:
>> THE NEED:
>
>
> Thank you for summary of needs. =A0Following is problems I feel (and
> discussed on IRC).
>

Hello Koichi-san,

> Problems:
>
> (1) Most of MRI developers (is it true?) can't change RubySpec. =A0Also
> most of MRI developers don't know RubySpec rules.
>

Commit bit can be given to the ones that ask, they just need a GitHub accou=
nt.

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. =A0If 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/*". =A0It 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. =A0For example, some modification=
s
> are revertd soon. =A0Should we add such features as "Specifications"? =A0=
(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). =A0It is independent as Ruby
> language, but dependent on MRI. =A0Where 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. =A0But we need "someone".
>
> Other solution is MRI committer join to maintain RubySpec. =A0MRI
> 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. =A0It is also one solution. =A0Howeve=
r,
> we need "someone" who can migrate. =A0It 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)

--=20
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=E9ry