(1) I explained to Fons in person and to everyon on the jack-devel mailing list what the issues with Fons' original patch. Robin Gareus has eloquently restated the basic point, but I'll do it again: the ability to REVIEW code changes is critical to long-lived projects, and when a change consists of 85% or more white-space/code style changes and only 15% actual functional differences, code review becomes all but impossible. I would like to bequeath future JACK1 maintainers the ability to go back and understand the changes from Fons, but that is absurdly hard to do when so much of the commit would be absolutely irrelevant.
(2) I also documented my process for attempting to test Fons' changes. To repeat:
(1) copy the entire code tree, twice
(2) clean up the first copy with uncrustify, which implies a canonical coding style throughout. test this version for several days to identify any obvious regressions from what should be a no-op.
(3) apply fons' patches to the second copy
(4) run uncrustify on the result, which makes it similarly canonical in terms of coding style.
(5) generate a diff between the two copies which theoretically should show only the functional differences introduced by fons
(6) apply the diff and commit
(7) test
Initially, things seemed to go well during test (otherwise I would not have pushed). But over a period of a couple of weeks, which in my case typically involves running Ardour endless times a day, often crashing it, while other clients run along in the background, I got the distinct impression that the server was no longer stable in the face of misbehaving clients. I did a git bisect, as did others, and we confirmed that commit that occured at step (6) above was responsible. I then reverted that commit (visible on jack-devel).
There are many other important changes in jack1 git that need to be released. Unless someone can identify what is wrong with the reverted commit, it will remain reverted, and I will release 0.125 without it (and then depart for post-JACK-ness nirvana).
--p