Ongoing elimination of multithreaded issues with River code is causing
division among remaining developers.
To make matters worse, due to the sheer number of issues found, the
protacted duration required to fix them would likely make the situation
worse, this work needed to be completed in a short period of time,
however it has taken far longer than desired.
For this reason, I'm considering whether the code in qa_refactor should
no longer form the basis of a release.
What I would expect this to do is remove tensions over perceived risks
of change.
If this proposal is supported, I'd also reccommend that trunk be
reverted back to the 2.2 River branch, with the exception of Sim's work
on ClassLoading, which should be included.
Provided there is support, change trunk to review then commit without
lazy concensus.
I would finish the work on qa_refactor and solve the remaining
multithreaded issues (on a longer lower pressure time schedule), the
River community can then decide whether it wants to use code from
qa_refactor on an as needed basis. I believe that the River community
will find this code a useful reference for latent multithreaded bugs.
Regards,
Peter Firmstone.
