Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology

[Olof Johansson <olof@lixom.net>]

On Sat, Jul 4, 2020 at 5:00 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sat, Jul 4, 2020 at 2:25 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > Could we just lose this entire document?
>
> I have to agree. I see no value to it except as a source of heated
> discussion and non-productive flame wars.

I think it has 2-3 purposes:

1) To motivate the change.
2) To have one place to point people at when new, often not active
community participants, chime in with more "what about" questions,
instead of having the same discussions over and over.
2b) Paragraph 5, and see below for more about that.

For changes to code, we sort of have one/two good places to document
why a change is introduced already:

1) For patches, the patch description. It'll live forever in the git history.
2) For branches, the merge commit. Useful in particular to document
any comments when merging code by a maintainer, but also as an
overview if there's a bunch of patches in the branch.

So, would it make sense to rework the contents and include it in the
patch description instead? Still easy to point people at in the git
history, and maybe a bit less of a sore spot.

> We can't start denying colours. What's next? Yellow and red and brown
> not being acceptable either?
>
> Red-black trees really must be the worst kinds of data structures,
> because in addition to the dangerous color mentions, the "trees" they
> talk about might be all about the historical lynchings of
> african-americans and native americans?
>
> Which I obviously bring up entirely because it's an example of just
> stupid things to argue about, rather than anything productive.
> Obviously rbtrees are nothing of the sort, and anybody who thinks they
> are should simply not be doing kernel development.
>
> At some point, maybe we should admit that we are inclusive, but also
> just admit that we don't want to have the kinds of people who instead
> of doing kernel development, waste everybody's time with talking about
> the meaning of the word "black".

I think there's a difference between listening to the community
members that are affected by this, considering their proposals such as
Dan's in this case, and debating this with random people on the
internet.

Dan's 5th paragraph in the file actually applies quite well to the
current discussion:

"Of course it is around this point someone jumps in with an
etymological argument about why people should not be offended.
Etymological arguments do not scale. The scope and pace of Linux to
reach new developers exceeds the ability of historical terminology
defenders to describe "no, not that connotation".  [...]"

I also don't think we're going to be able to leave all of this behind
us with or without the file with the motivation being merged. I
personally see more benefit than drawback of including it, especially
for paragraph 5 since that will come up over and over again.


-Olof