Revert the reimplementation of TBQueue

[nikita-volkov]

I've managed to reproduce one issue in #76 and provide a fix for it in #77. However I'm experiencing other race conditions on 2.5.2.1, which were not present on 2.5.1.0. It's hard to reproduce though.

Any way, it means that there is at least two bugs in the reimplementation and it has no test coverage. So there may be more.

Until the new implementation is covered with exhaustive tests and is fixed I suggest to roll back and deprecate the 2.5.2.0 and 2.5.2.1 releases.

Regarding an exhaustive test model for the new implementation I've made a suggestion here: #76 (comment).

[konsumlamm]

I'd recommend adding property tests (e.g. using QuickCheck). While we're at it, we can also replace test-framework by tasty (which is more actively developed).

Currently there are two test suites, one in tests/ and one in testsuite/. It seems tests/ is just for GHC? It would be nice to unify the two.

[TeofilC]

Another way forward might be to start off with the new implementation as a TBQueue.Experimental variant or something like that and only replace the old version with it after a while has passed and we've worked out the kinks

[simonmar]

We should probably roll it back until we have better testing. @bgamari would you be able to do that?

[bgamari]

Yes, I can roll-back.

FWIW, I agree that we need better testing; it has long been concerning to me that such a subtle system as STM has as little testing infrastructure as it does.

[bgamari]

Reverted in #80.

[bgamari]

I have released 0.5.3.0 with the TBQueue rewrite reverted.

@konsumlamm , perhaps you would like to have a stab at improving stm's testsuite and then trying your change again?

[nikita-volkov]

Thank you! Can we also deprecate 2.5.2.0, 2.5.2.1 on Hackage since they are buggy?