On 3/29/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Mar 29, 2007, at 4:20 PM, jerry gay wrote:
> On 3/29/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
>> > <particle> and i'm not interested in testing every
>> revision,
>> > when so many might be coding standards
>>
>> Why are people even checking things in that fail coding standards?
>
> because not all coding standard tests are run with 'make test'. some
> tests were still under development, or too noisy, or took too long.
> this means that running
> make test
> and running
> prove t/codingstd
>
> will give you *very* different results. the correctness and
> performance problems with coding standard tests have largely been
> solved, and i'm now in favor of enabling all these tests during make
> test. this will require a large number of commits up front to fix the
> current list of failures, but would prevent developers from committing
> code that's not up to snuff.
>
> ~jerry
Should we even require all of these tests to be ran by default? These
tests should never fail for a user compiling a release version of
parrot, so should they need to test them? They're good for developers,
but only developers. And from a prove t/codingstd, should parrot's
tests test any of languages? A language's coding standards should be a
personal preference of the language author. Plus, some of the failures
are from the tests testing documentation as well as source, so it seems
to be slightly exaggerated.
until we stop actively developing major subsystems we should be
running these tests regularly. no test should fail for a user
compiling a release version of parrot. should we run any tests at all?
of course.
we exclude languages from coding standard tests as a general rule. if
some tests are testing languages/ files, either the test is broken, or
the authors requested it (e.g. t/codingstd/perlcritic.t.) there have
been tickets entered for this in the past, and just yesterday i
cleaned up two test files that were testing languages--work in this
area continues. this is part of the correctness measure i mentioned
has "largely been solved." please enter tickets for anything that
looks wrong, we'll get it fixed up.
our documentation has standards, too. for example, every op should
have a doc; no trailing spaces; line length, etc. i can't see a reason
not to test documentation.
~jerry
