XFAIL a check on length of results in test_gracefull_death

[yarikoptic]

Still happens in some busy environments, like recently within https://app.travis-ci.com/github/datalad/datalad/jobs/586725682 of #7118

Attn @bpoldrack who was after all the flaky tests

[bpoldrack]

I'm kinda fine with this approach. Hence the approval.

However, I see little utility in having the test executed in the first place. Nobody was able/willing to figure it out while it was making CI fail, I predict nobody will care about an XFAIL either. So, whatever the outcome of the test - there will be no consequences. IMHO it's just wasted runtime.

[yarikoptic]

Nobody was able/willing to figure it out while it was making CI fail

from my observation - busy system. And that was at large reason for majority of other fails in test_parallel -- consumer threads are not executed in the number/order expected by the test.

So, whatever the outcome of the test - there will be no consequences. IMHO it's just wasted runtime.

In general (not this particular xfail assert for which takes virtually no time) I agree to disagree: the test has other conditions and possibly even contributes uniquely to code coverage. As with any test, "they are useless" after possibly initial TDD is done and until some changes in environment or code make them resurface problems again. But I do agree that XFAILs are largely forgotten about, as well as our @known_failures.

Ok, overall, with this blessing let's proceed

[yarikoptic]

note: travis - filed #7129 . appveyor -- seems like that new git/git-annex giving us issues we can no longer postpone looking at :-/ #7116

[yarikoptic-gitmate]

PR released in 0.17.9