[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d664ff641dbf3aeab1ecd5eacda220dab9d7d17.camel@intel.com>
Date: Tue, 9 Jun 2020 19:30:50 +0000
From: "Williams, Dan J" <dan.j.williams@...el.com>
To: "stephen@...workplumber.org" <stephen@...workplumber.org>,
"davem@...emloft.net" <davem@...emloft.net>
CC: "corbet@....net" <corbet@....net>,
"andrew@...n.ch" <andrew@...n.ch>,
"amitc@...lanox.com" <amitc@...lanox.com>,
"david@...tonic.nl" <david@...tonic.nl>,
"linville@...driver.com" <linville@...driver.com>,
"marex@...x.de" <marex@...x.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"petrm@...lanox.com" <petrm@...lanox.com>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"christian.herber@....com" <christian.herber@....com>,
"mkubecek@...e.cz" <mkubecek@...e.cz>,
"kuba@...nel.org" <kuba@...nel.org>,
"o.rempel@...gutronix.de" <o.rempel@...gutronix.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"mkl@...gutronix.de" <mkl@...gutronix.de>,
"f.fainelli@...il.com" <f.fainelli@...il.com>
Subject: Re: [PATCH ethtool v1] netlink: add master/slave configuration
support
On Tue, 2020-06-09 at 11:36 -0700, David Miller wrote:
> From: Stephen Hemminger <stephen@...workplumber.org>
> Date: Tue, 9 Jun 2020 10:19:35 -0700
>
> > Yes, words do matter and convey a lot of implied connotation and
> > meaning.
>
> What is your long term plan? Will you change all of the UAPI for
> bonding for example?
The long term plan in my view includes talking with standards bodies to
move new content to, for example, master/subordinate. In other words,
practical forward steps, not retroactively changing interfaces.
> Or will we have a partial solution to the problem?
Partial steps toward better inclusion are meaningful.
The root problem is of course much larger than a few changes to
technical terminology could ever solve, but solving *that* problem is
not the goal. The goal is to make the kernel community as productive as
possible and if the antropomorphic association of "slave" can be
replaced with a term that maintains technical meaning it makes kernel-
work that much more approachable.
I recall one of Ingo's explanations of how broken whitespace can make
patches that much harder to read and take him out of the "zone" of
reviewing code. "Slave" is already having that speed bump affect on the
community. If we can replace it without losing meaning and improving
the effectiveness of contributors I think the Linux kernel project is
better for it.
Powered by blists - more mailing lists