On Wed, Mar 30, 2016 at 3:31 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Tue, Mar 29, 2016 at 11:12:21AM -0400, Paul Davis wrote:

> (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.

1. All the places where the actual code was changed were
   clearly identified by comments.

That is of close to ZERO help to someone who is trying to read a large commit and understand what was changed.

I have no idea why you keep pushing this point. It is simply an utterly accepted feature of every open source project that involves distributed developers that you do not change the whitespace/indent/coding style, no matter how much you dislike it. I've worked on projects that would have just rejected your entire patch based on this aspect alone. I mentioned this to you in private.

Instead, I took time to investigate code formatters, identify which one would likely do the right thing, and come up with a strategy for creating a commit that only changed what actually mattered.
 

2. When I compare the commit (42393121) that applied my patch
   with previous versions, there are *lots of* major coding
   style and whitespace changes in files that I never touched.
   This means the coding style wasn't consistent to start with.

Nobody is questioning this. That is why my process for dealing with your patch FIRST involved using uncrustify to canonicalize the coding style. Normally I would not have bothered to do this, since it created a huge commit that in theory is a 100% no-op, and wasn't addressing any actual reported problem or issue. But it was the only way I could see to convert your patch into an acceptable format. This particular step would have been unnecessary without all the extra changes in the original patch.
 

3. When I read that same commit (which I assume reflects the
   preferred style) I see things like this:

It reflects the work of uncrustify. I have attached the config file that I used. I am entirely happy to consider revisions to the uncrustify config file and we can re-run the canonicalization step. I'm entirely open to the idea that I didn't get the uncrustify config correct, and that there are better options to be used in order to achieve the desired result. I'm happy to take suggestions on how to improve this.

Let me re-describe the scenario that we're discussing here:

I received a valuable but terribly formatted patch that changed large amounts of code for no reason at all. Rather than reject it, I mentioned this to its author, who basically shrugged and said "it is what is is, this is how i work", completely ignoring convention in distributed development. I spent time to come up with a strategy for generating a clean(er) version of the patch, which either because of errors in the process or errors in the original patch, caused a regression in server stability in the face of less-than-well-behaved clients. After some discussion on jack-devel, I reverted the commit.

At this point, the pushback I am getting is leading me towards simply rejecting the work out of hand and forgetting about it. The change/fix is an important one, and I want to see it included in jack1's codebase. But I will not put up with this BS attitude toward a problem that started when Fons chose to ignore conventional behaviour and believed that submitting a patch which was 80%+ reformatting changes was an acceptable strategy.