Whitespace and bullying

[ronnie sahlberg]

Not sure I understand why this topic is so controversial and needs so
much discussion.

I think all can agree that it is a waste of time for a human to look
for basic codestyle errors
such as whitespace and friends.

Lots of projects have checkpatch scripts or similar that do these
checks automatically and policy that all contributors
are supposed to "don't post the patch until checkpatch runs cleanly".
It works well for those projects. I am certain
it would work well for samba too.

I just don't see the problem or controversy.


On Mon, Apr 9, 2018 at 9:38 AM, Martin Schwenke via samba-technical
<samba-technical at lists.samba.org> wrote:
> On Mon, 09 Apr 2018 10:41:07 +1200, Andrew Bartlett
> <abartlet at samba.org> wrote:
>
>> On Sat, 2018-04-07 at 20:32 +1000, Martin Schwenke wrote:
>> > On Sat, 07 Apr 2018 20:18:29 +1200, Andrew Bartlett
>> > <abartlet at samba.org> wrote:
>> >
>> > > On Sat, 2018-04-07 at 16:44 +1000, Martin Schwenke wrote:
>>  [...]
>> > > We need to practice what we preach.  Many contributors (myself if you
>> > > need a specific example) pattern far better by example of the code
>> > > nearby than rule-books.
>> > > If the majority of our code doesn't comply with README.Coding then the
>> > > rule shouldn't be in README.Coding.
>> >
>> > While I agree, I'm working hard to accomplish some particular goals.
>> > Those goals don't include getting sidetracked by having to fix
>> > coding standard violations in comments in code that I'm hoping to
>> > remove.  I already feel over-committed and under pressure.
>>
>> I totally agree, but in a different way.
>>
>> The sheer amount of time and passion directed on this point, is why I'm
>> calling bullshit on this rule, and why I say this isn't really about
>> whitespace at all, but about power and control.
>>
>> Asking developers, new or experienced, to match a whitespace guide that
>> you can't see without filters and that much of our code doesn't honour
>> on pain of public flagellation (but without our CI advising ahead of
>> time) is just stupid.
>>
>> We could perhaps save that for code going in without tests, which
>> happens all the time and isn't commented on, or actually saying well
>> done, like Andreas did.
>>
>> If the whole team held to that positive review culture, or if those who
>> continue to raise had made any effort to read the actual code to
>> provide a balanced an productive comment, that would be a very
>> different thing.  But code review by a significant number of team
>> members, Volker in particular, has degenerated into the two categories
>> of:
>>  - 80 Columns
>> and
>>  - whitespace
>>
>> Now, I've just make it personal above, and perhaps this is where this
>> thread will totally derail.
>
> Let me make it impersonal again.  ;-)
>
> Let's say we have a rule in README.Coding and that contributor X
> doesn't set up their editor to help them adhere to that rule, they
> produce changes that break that rule and those changes then make it
> into the tree.
>
> Then contributor Y, who does set up their editor to help them adhere to
> that rule, opens a file that breaks the rule in their editor.  They see
> distracting highlights throughout the code.  The only reasonable way
> they can sanely work on the code is to make the code adhere to the
> rule so that the highlights in their editor go away.
>
> This is unfair.  The person who has set up their editor to help them
> adhere to the rule spends their time fixing other people's breaches of
> the rule.
>
> Perhaps what we really need is an induction document that lists
> technical things that can help team members adhere to the rules?
>
> peace & happiness,
> martin
>