Allison Randal schrieb:
I saw the failing test, but didn't know where it came from or why it
was there. (And until I dug into it the commit logs, I didn't even
know if it was an old test that I had broken while working on the
threads tests.)
I added this failing, as the test '1 equals 1' in
languages/lisp/t/arithmetics.t started failing after
the merge. Investigating that failure, I found that I could reproduce
the problem with a simple
PIR test case. This is what I added in t/pmc/objects.t. So it's a test
for something that was previously
working.
I don't see why. I'd like to see Parrot be in a releasable state
with every checkin. That's why we have the tests.
I support this as a rule. I broke it when I merged in the pdd15oo
branch with 4 failing tests because I was planning to fix them right
away. I did cut it down to 3 failing tests, and resolved the surface
issues with the remaining 3. But, there's a deeper issue with cloning
vtable overrides across threads that I haven't resolved yet (the
interpreter cloning code is sorely in need of a rewrite). So, I'll
mark those as TODO, with a reference to the tickets that James created
(thanks, James!).
Yes, that's the intention of 'TODO' as I understood. Tests that are
failing because something isn't done
yet. But IMHO somebody should look at the issue and classify it as TODO.
IMHO the classifier doesn't have to be submitter of the test case, as
there should be
a low entrance barrier for adding tests.
Regards,
Bernhard
Allison
