In <[EMAIL PROTECTED]>, Michael G Schwern writes:
:> It is currently an (apparent) no-no to add tests to perl that fail.
:> While I can understand the desire to avoid distressing end users
:> with fully anticipated test failures, I think we need a better
:> solution to this - when a problem is identified, the _first_ thing
:> that should appear is the new test that identifies the problem by
:> failing. Just because we're not sure how to fix the problem yet,
:> or haven't had the tuits yet, is no reason not to add the failing
:> test.
:
:On stable (maintenance) Perl releases the answer is clear.  EVERYTHING
:PASSES.  Something fails, we don't release.
:
:For devel perls, its murky what the right thing to do is.  You're
:definately right about needing to add the tests, failing or passing.
:It will obviously be necessary to release devel versions of Perl with
:tests that fail.  At a minimum we can have a formal way to specify
:that we expect a test to fail.  "On these OS's, with these libraries and
:these configs this test is expected to fail.  See bug #23234" or
:something like that.  Only written explicitly in a way Perl can
:understand.
:
:This issue is big enough to warrent a seperate discussion/RFC.

Agreed. When that comes, I'll argue that it is perfectly acceptable
to release a "stable (maintenance) Perl" with known test failures.

I'm off for a few days (back next Wednesday), so be good.

Hugo

Reply via email to