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

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Olof Johansson <olof@lixom.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	tech-board-discuss@lists.linuxfoundation.org
Subject: Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology
Date: Mon, 06 Jul 2020 19:52:00 -0700	[thread overview]
Message-ID: <1594090320.22278.14.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAOesGMi_byg0i1-iT5asj29f7PEjA5Oco=mU4Kmtrd3e4MfhqA@mail.gmail.com>

On Mon, 2020-07-06 at 19:05 -0700, Olof Johansson wrote:
> 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.

What's wrong with "because we have more descriptive terms"?  In the
whole long argument, no-one has disagreed with the idea that we can
replace master/slave and black/white list with better and more
descriptive terms.  What all the wittering has been about is the
statements in this document and their suspected motivation.

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

I really don't think where you put it is the problem people are
reacting to.  I agree that since commit logs are unamendable, it
forestalls all the proposed patches to update it but it still doesn't
head off the argument we're having now.

> > 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".  [...]"

Just because you foreshadow the argument doesn't excuse you from
causing it.  I repeat the point: in all the huge thread no-one has
objected to amending the coding style to suggest more inclusive
language.  That means we can get way more people to agree to changing
the coding style than we can to agree with including this document.

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

Well now you're making me wonder: what is the motivation here? is it to
change the language in the kernel or is it to make a political
statement?  Your argument is starting to make me think the latter and
that's really going to attract the conspiracy nuts.

James